Time Woes [message #30471] |
Wed, 01 May 2002 12:41  |
David Fanning
Messages: 11724 Registered: August 2001
|
Senior Member |
|
|
Folks,
OK, I'm completely lost.
I've been perusing the JHAPL IDL library for days, it seems like,
but my eyes are still crossed.
I have a time array that purports to be the number of seconds
from 1 Jan 1980. How in the world do I convert that to something
I can use with routines I have access to?
Thanks,
David
--
David W. Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
Re: Time Woes [message #30547 is a reply to message #30471] |
Thu, 02 May 2002 15:26   |
Craig Markwardt
Messages: 1869 Registered: November 1996
|
Senior Member |
|
|
David Fanning <david@dfanning.com> writes:
>
> Here is what I know. I have some TRMM data in a particular
> lat/lon range at a particular time (e.g. 4AM on 7 July 2001).
> I want to pull out any QSCAT wind data that might overlap my
> TRMM data by about an hour or two.
>
> What questions would it be helpful for me to know to ask?
Hey David--
Everybody is bothering you about TAI, UTC, leap seconds, you must be
going crazy! If you are just interested in precisions of overlaps of
"an hour or so" then you really don't care about leap seconds, so you
can probably forget about most of it. (just wait until you get to TT,
TDT, TDB, TCG and TCB!)
For doing overlaps the real necessity is to get the times of your TRMM
data and QSCAT data into the same format, doesn't matter what format
that is. One easy one is to use Julian days as Ben, et al have been
describing. You have a "seconds-since-epoch" format, so you would
indeed take:
t_trmm = .... ;; Seconds since 1980
;; Convert to Julian days (86400 seconds per day)
jd_trmm = julday(0,1,1980, 0,0,0) + t_trmm/86400
and then you probably have to do something similar to the QuikScat
times, right?
Craig
--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
|
|
|
Re: Time Woes [message #30548 is a reply to message #30471] |
Thu, 02 May 2002 14:51   |
thompson
Messages: 584 Registered: August 1991
|
Senior Member |
|
|
btupper@bigelow.REMOVE.org (Ben Tupper) writes:
> On Wed, 1 May 2002 13:41:10 -0600, David Fanning <david@dfanning.com>
> wrote:
>> I have a time array that purports to be the number of seconds
>> from 1 Jan 1980. How in the world do I convert that to something
>> I can use with routines I have access to?
>>
> Howdy,
> Do you mean that you want to know a Julian time stamp or Calendar date
> for the time array values? I don't have IDL in front of me right now
> so I can't check this, and I can't clearly recall the syntax.
> (The following supposes the 'seconds' are just the run-of-the-mill
> kind of seconds...)
> ; start time in seconds
> t0 = JulDay( 0,1 1980, 0, 0, 0)
> ; add the elapsed time since t0
> t[i] = t0 + timeArray[i]
> ;convert to calendar values
> CalDat, t[i], month, day, year, hour, min, sec
> I have a sneaky feeling that your problem is more complicated than
> this solution will bridge. The only thing I do well with time (in
> IDL) is squander it, but I hope it helps anyway.
There is an ambiguity in the problem. It isn't obvious whether the seconds in
timeArray include leapseconds or not. In other words, is it a UTC-based time,
or a TAI-based time? The difference in the two between 1-Jan-1980 and today is
13 seconds. Depending on your point of view that could be negligable or a
major mistake.
My gut feeling is that your data is UTC-based. This would make it comparable
to Unix time, which is the number of (non-leap) seconds since 1-Jan-1970, and
which in IDL is returned with SYSTIME(1). In that case, using the JulDay and
CalDat procedures would give you exactly the correct answers.
If on the other hand, the data you have is TAI-based, and you care about the
distinction, you might want to check out my routines utc2tai.pro and
tai2utc.pro, which are available at
ftp://sohoftp.nascom.nasa.gov/solarsoft/gen/idl/time/
William Thompson
P.S. By the way, wouldn't that be
; start time in seconds
t0 = JulDay( 1,1, 1980, 0, 0, 0) * 86400.D0
;^)
|
|
|
CDF_EPOCH (was Re: Time Woes) [message #30550 is a reply to message #30471] |
Thu, 02 May 2002 12:05   |
Brian Jackel
Messages: 34 Registered: January 1998
|
Member |
|
|
Hi
I've found the CDF_EPOCH routine to be very
useful for this kind of thing. For your example
CDF_EPOCH,epoch0,1980,1,1,0,0,0,/COMPUTE
CDF_EPOCH,today,2002,05,02,12,50,30,/COMPUTE
dt= (today-epoch0)/1.0d3 ;difference in seconds
This doesn't directly address the tricky question
of leap-seconds, but the CDF source code is available
(http://nssdc.gsfc.nasa.gov/cdf/cdf_home.html)
so in theory you could check it to see what goes on
inside.
Brian
David Fanning wrote:
>
> Folks,
>
> OK, I'm completely lost.
>
> I've been perusing the JHAPL IDL library for days, it seems like,
> but my eyes are still crossed.
>
> I have a time array that purports to be the number of seconds
> from 1 Jan 1980. How in the world do I convert that to something
> I can use with routines I have access to?
>
> Thanks,
>
> David
|
|
|
Re: Time Woes [message #30554 is a reply to message #30471] |
Thu, 02 May 2002 08:34   |
Struan Gray
Messages: 178 Registered: December 1995
|
Senior Member |
|
|
David Fanning, david@dfanning.com writes:
> it suddenly occurred to me that I was earning
> less as an IDL programmer than I was earning as a tennis
> coach. The idea of explaining *that* to my wife left me
> in a cold sweat.
It can help to talk. When I was once complaining about IDL time
functions my wife gave me the old Monty Python "you were looky..."
rant. She deals with time series in the sixteenth century. The year
number changes on different dates in different countries. Within the
same country it can change on different dates for different types of
record, and the different levels and types of law court all used
different days too. Best of all, the switch to the Gregorian calender
was in mid-swing, so weeks and days disappear whilly nilly from
various months of the year, and at different times in all the
different countries, palatinates and free republican cities. The
Swedes - bless 'em - not only made the switch last, they spread it
over several years, catching up one day at a time.
Compared to that, a relativistic correction for the orbital
velocity of a satellite is child's play.
Struan
|
|
|
Re: Time Woes [message #30557 is a reply to message #30471] |
Thu, 02 May 2002 06:38   |
David Fanning
Messages: 11724 Registered: August 2001
|
Senior Member |
|
|
Ben Tupper (btupper@bigelow.REMOVE.org) writes:
> Do you mean that you want to know a Julian time stamp or Calendar date
> for the time array values? I don't have IDL in front of me right now
> so I can't check this, and I can't clearly recall the syntax.
>
> (The following supposes the 'seconds' are just the run-of-the-mill
> kind of seconds...)
>
> ; start time in seconds
> t0 = JulDay( 0,1 1980, 0, 0, 0)
> ; add the elapsed time since t0
> t[i] = t0 + timeArray[i]
> ;convert to calendar values
> CalDat, t[i], month, day, year, hour, min, sec
>
> I have a sneaky feeling that your problem is more complicated than
> this solution will bridge. The only thing I do well with time (in
> IDL) is squander it, but I hope it helps anyway.
I think what I want is something about as simple as
this. I was in a panic yesterday because I had
bid on that job as a project, rather than on an hourly
basis, and it suddenly occurred to me that I was earning
less as an IDL programmer than I was earning as a tennis
coach. The idea of explaining *that* to my wife left me
in a cold sweat. Sorry for taking it out on the newsgroup. :-(
Cheers,
David
--
David W. Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
Re: Time Woes [message #30559 is a reply to message #30471] |
Thu, 02 May 2002 06:11   |
btupper
Messages: 55 Registered: January 2002
|
Member |
|
|
On Wed, 1 May 2002 13:41:10 -0600, David Fanning <david@dfanning.com>
wrote:
> I have a time array that purports to be the number of seconds
> from 1 Jan 1980. How in the world do I convert that to something
> I can use with routines I have access to?
>
Howdy,
Do you mean that you want to know a Julian time stamp or Calendar date
for the time array values? I don't have IDL in front of me right now
so I can't check this, and I can't clearly recall the syntax.
(The following supposes the 'seconds' are just the run-of-the-mill
kind of seconds...)
; start time in seconds
t0 = JulDay( 0,1 1980, 0, 0, 0)
; add the elapsed time since t0
t[i] = t0 + timeArray[i]
;convert to calendar values
CalDat, t[i], month, day, year, hour, min, sec
I have a sneaky feeling that your problem is more complicated than
this solution will bridge. The only thing I do well with time (in
IDL) is squander it, but I hope it helps anyway.
Ben
|
|
|
Re: Time Woes [message #30560 is a reply to message #30471] |
Thu, 02 May 2002 06:07   |
Ken Mankoff
Messages: 158 Registered: February 2000
|
Senior Member |
|
|
On Wed, 1 May 2002, Paul Van Delst wrote:
> David Fanning wrote:
>> Ken Mankoff (mankoff@I.HATE.SPAM.cs.colorado.edu) writes:
>>> First, before you deal with any conversions, you have to understand
>>> exactly what it means to have "seconds since 1980".
>>
>> What questions would it be helpful for me to know to ask?
>
> Is the time "regular" time, or atomic time?
I would not ask anything as eloquent as this. I would ask 1 of 2
things. First, "Can I get the data on a different grid", and second
would be what I asked you: A long rambling paragraph asking how many
seconds are in a year, etc. So I suggest you take Paul's advice.
> p.s. I always thought the "seconds since 1980" time was a relatively
> common thing.
I always thought that "time" was a relatively common/simple thing
too... until I started working with satellites and space.
I think "seconds since 19X0 (where X is 7 or 8)" is common in
computers, and that the computer community assumes 60s*60m*24h*365d
seconds in a year, unless its a leap-year. I would guess this is what
Davids time-scale is, but if its not, the errors between the above
equation and whatever his time is on will add up (especially if you
add up 20 years of errors, and stop right before a leap-year when the
errors "reset" a bit), that he will not be looking at data within 2
hours of each other.
-k.
--
------------------------------------------------------------ ---------------
Ken Mankoff http://lasp.colorado.edu/snoe/
http://lasp.colorado.edu/mars/
http://lasp.colorado.edu/~mankoff/ http://lasp.colorado.edu/marsrobot/
------------------------------------------------------------ ---------------
|
|
|
|
Re: Time Woes [message #30568 is a reply to message #30471] |
Wed, 01 May 2002 14:00   |
David Fanning
Messages: 11724 Registered: August 2001
|
Senior Member |
|
|
Ken Mankoff (mankoff@I.HATE.SPAM.cs.colorado.edu) writes:
> First, before you deal with any conversions, you have to understand
> exactly what it means to have "seconds since 1980".
Well, you see, that's the whole problem with the consulting
business. Even when you have it together enough to ask a
question like this, the chance that your client might know
the answer is about nil. Otherwise, they would be writing
the program themselves.
Here is what I know. I have some TRMM data in a particular
lat/lon range at a particular time (e.g. 4AM on 7 July 2001).
I want to pull out any QSCAT wind data that might overlap my
TRMM data by about an hour or two.
What questions would it be helpful for me to know to ask?
Cheers,
David
--
David W. Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
Re: Time Woes [message #30570 is a reply to message #30471] |
Wed, 01 May 2002 13:10   |
Ken Mankoff
Messages: 158 Registered: February 2000
|
Senior Member |
|
|
On Wed, 1 May 2002, David Fanning wrote:
> I have a time array that purports to be the number of seconds from 1
> Jan 1980. How in the world do I convert that to something I can use
> with routines I have access to?
First, before you deal with any conversions, you have to understand
exactly what it means to have "seconds since 1980".
What clock system are you on? Is it 365 day years (and leap-years), or
365.25, or something more accurate than that? The clocks here at work
have leap-seconds thrown in every few months (I believe this is one of
the many subtle distinctions between UTC, GMT, and Zulu, but am not
sure).
Then again, depending on the resolution of the data (and x-axis if you
are plotting it), does any of these different "times" matter to you?
Beyond that, I am not sure what you want to convert it to... Can't you
just start doing division until you have it into "days since 1980"?
The other option is to add 10 years worth of seconds onto the array
(again: exactly how many seconds are there in your year calendar?),
now you have it as seconds from 1 Jan 1970. This is the same format as
UNIX and the IDL SYSTIME() function, so you should be able to handle
this array better...
Does this help?
-k.
--
------------------------------------------------------------ ---------------
Ken Mankoff http://lasp.colorado.edu/snoe/
http://lasp.colorado.edu/mars/
http://lasp.colorado.edu/~mankoff/ http://lasp.colorado.edu/marsrobot/
------------------------------------------------------------ ---------------
|
|
|
|
Re: Time Woes [message #30700 is a reply to message #30548] |
Thu, 09 May 2002 07:21  |
btupper
Messages: 55 Registered: January 2002
|
Member |
|
|
On 2 May 2002 21:51:20 GMT, thompson@orpheus.nascom.nasa.gov (William
Thompson) wrote:
>
>> ; start time in seconds
>> t0 = JulDay( 0,1 1980, 0, 0, 0)
>> ; add the elapsed time since t0
>> t[i] = t0 + timeArray[i]
>> ;convert to calendar values
>> CalDat, t[i], month, day, year, hour, min, sec
>
>
> P.S. By the way, wouldn't that be
>
> ; start time in seconds
> t0 = JulDay( 1,1, 1980, 0, 0, 0) * 86400.D0
>
Oo, right! That would make a teeny difference... on the other hand,
that's nothing that David couldn't convincingly arm wave about.
Ben
|
|
|