Hello Alan,
I think we're converging here. Certainly dispensing with leap seconds
removes nearly all the complications.
All the possible time systems (e.g., GPS, TAI, NASA CDF Epoch) differ
only by a constant offset and, as you point out, if the user wanted to
pretend that GPS was actually UTC (without leap seconds) they could do
so simply by passing a broken-down-time that corresponded to what they
want the data to represent and the plot to show.
I had some doubts about specifically advertising our plplot time as GPS
for the following reasons:
1 GPS has a precisely-defined t=0. That might encourage (= not
discourage) users from calculating it themselves rather than using our
plplot-to-be-supplied routines. In our experience that can lead to
errors that are avoided if perfectly matched build-up/break-down
routines are used.
2 I guess negative gps time is not defined, though could easily be
extended to do so.
3 gps is clearly intended to be relatively localised; it is usually
used as week number and seconds, and the week counter rolls over after
20 years.
So I was going to propose adopting TAI instead. But all we really need
to do is provide a visible mapping from a continuous variable to
(YYYY-MM-DD:HH:MM;SS.SSS...) and this can be presented to the user
without specifying where the zero for the continuous variable is. Thus
we could accommodate time in any system; that would save the user the
trouble of re-calculating timetags, and they could label the time axis
with the appropriate label (UT, TAI, Time since birth of my 2nd child,
or whatever).
One mechanism to do this would be to add a pair of arguments to the
appropriate plplot routine(s) so that the user gives the broken-down
time and the value of the T-variable they will be passing to plot to
which that time corresponds. Then we can internally calculate the offset
between the user's time reference and our own internal one (TAI, say)
and do the internal shifting ourselves, rather than forcing the user to
prepare all the data to meet our time specification.
We'll need to think a bit about whether to shift all the times in the
time series or only shift what we need to divide and label the axes. The
advantage of the latter is that if the user picks up a value
interactively from the plot it will get returned to them in a world
coordinate that they will understand, i.e., that will match the values
they passed to plplot in the T-variable.
This is a detail we can discuss, but in the meantime we can start to
work on:
1 Build-up and break-down routines
2 Handling time more accurately than can be done in a single double
(which fails somewhere in the micro- to millisecond range) by using two
variables
3 Writing our own strftime to match. I would suggest that we use the
same format specifiers as strftime where possible, but offer a more
limited set. I would suggest to start with the equivalents of:
YYYY, YY, MM (1-12), MON ("Jan", "Feb", ...), MONTH ("January", ...), DD
(1-31), DOY (Day-of-Year 1-366), HH (0-23), MIN (0-59), SS (0-59), ssss
(fractional part of seconds to as many decimals places as there are
"s"'s in the format specifier, or a %<N> where N is the decimal place
counter).
These would then be, if I've read the strftime spec correctly):
%Y, %y, %m, %b, %B, %d, %j, %H, %M, %S, plus our own %<N>
and would omit anything to do with the locale, AM/PM, week counters,
centuries, specifiers for compound forms (e.g., %R meaning %H:%M),
tabs, newlines, etc., etc.
4 A re-look at the default tick/sub-tick algorithms to try to avoid
dividing minutes, hours, and days into intervals of 5 sub-units (i.e.
not 5 seconds, 5 minutes, or 5 hours). In keeping with the suggestion in
(3) I would drop weeks altogether, otherwise add not dividing a week
into 5 sub-units to the above). Months and years are too nightmare-ish
to think about at present.
5 Probably write another example that provides more exhaustive time
handling; we'll need this anyway to test the changes.
Invited actions:
a) comments on first discussion re time system
b) comments on (3)
c) volunteer for (4) :-)
When my time expert (Tony Allen) gets back from jury service I'll ask
him to propose something for (2).
Regards,
Steve
On Wed, 2008-09-03 at 09:58 -0700, Alan W. Irwin wrote:
> Hi Steve:
>
> > But I would draw to you attention a real problem that lurks in this can
> > of worms. Suppose you want to plot two minutes of data that contains a
> > leap second [...]
>
> I agree its a can of worms to display results in UTC for time intervals that
> span leap seconds. Thanks for reminding me of this issue. Therefore I now
> suggest we bypass the whole UTC mess, and use GPS (which has no leap
> seconds) instead. See http://en.wikipedia.org/wiki/GPS#Timekeeping for a
> discussion of this time system which varies from TAI by a constant offset.
> If we adopted this, then both our fundamental time variable would be GPS (or
> TAI) with a constant known offset depending on what epoch we chose and our
> broken-down time would be GPS.
>
> In short, I have come around to your original idea of ignoring leap seconds
> altogether, but I now think this decision can be justified by relating our
> time scales to the well defined GPS time.
>
> We would have to be really clear in the documentation that we were using GPS
> time (which is currently different from UTC by 14 seconds with that
> difference increasing by roughly a second every 2 years) rather than UTC.
> However, GPS receivers are becoming ubiquitous so a lot of people are
> already familiar with the distinction between GPS time and UTC. To ram this
> home, the commands should be called pltimegps and plgpstime.
>
> Of course, if the user got the time offset wrong for GPS time and used UTC
> instead, all would be well provided (a) they were consistent, and (b) their
> time interval didn't span a leap second. But the advantage of the above GPS
> approach is we let them worry about leap seconds rather than us, and we give
> them an avenue to get everything right if they are on top of the offsets
> required to convert from their local time to broken-down GPS time.
>
> > [...] Blame it on the Earth.
>
> Indeed! :-)
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state implementation
> for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
> package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
> Linux Links project (loll.sf.net); and the Linux Brochure Project
> (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
--
+-------------------------------------------------------------------+
Professor Steven J Schwartz Phone: +44-(0)20-7594-7660
Space and Atmospheric Physics Fax: +44-(0)20-7594-7772
The Blackett Laboratory E-mail: [EMAIL PROTECTED]
Imperial College London Office: Huxley 6M70
London SW7 2BW, U.K. Web: http://www.sp.ph.ic.ac.uk/~sjs
+-------------------------------------------------------------------+
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
