On 2008-09-02 13:18+0100 Schwartz, Steven J wrote: > We don't deal with leap seconds. As long as we use our own routines to get from broken-down time to epoch time and back, the result is clean and consistent, although this means we only allow a minute to have 60 seconds. Thus a time series that actually spans across a leap second will be short by a second, but if all the times are calculated from broken-down times every point outside the leap second will be at its correct time. [All these approaches are borrowed from NASA CDF routines, although we've changed them to count in seconds rather than milliseconds.]
I think we should deal properly with leap seconds because of the problem you mentioned above and also the problem that our fundamental time variable would then have a strange relationship with externally defined time systems which might confuse our users. So I have looked into the issue of leap seconds some more. I looked up exactly how POSIX takes care of leap seconds at the above URL, and it is a real mess. See the example in the second table where a given Unix/POSIX time corresponds to two different UTC times. Ugh! So we should avoid a POSIX-based fundamental time variable. The NTP variant they discuss does not have the POSIX ambiguity problem at the expense of an extra variable to describe whether a leap second is being inserted or not. So this is one possible candidate for our fundamental time variable. However, I far prefer a fundamental time variable that always smoothly increases so a TAI based time variable (also discussed in the above article) appeals most to me for our fundamental time variable for the post-1960 epoch. Also using a fundamental time variable that is based on atomic time (or orbital observations prior to 1960, see below) rather than the irregular rotation rate of the earth appeals to me at the philosophical level. Also, this would allow our users to brag they had access to atomic time using PLplot. :-) One issue with using TAI is that time scale was not defined before 1960. Similarly, civil time took other forms than UTC before that epoch. The historical equivalent of TAI is ephemeris time (which goes back several centuries and is based on orbital observations) and civil time had a variety of definitions. I used to have the relevant references at my finger tips of how astronomers handled these conversions smoothly for ancient epochs, but its been a while since I have done research in this field so I would have to look those references up again. A good starting web reference appears to be http://www.ucolick.org/~sla/leapsecs/timescales.html. (I am sure that must be a good reference since it mentions my paper! :-)) Probably the best thing to do here is simply to adopt (and document!) a constant offset between our fundamental time scale and civil time prior to 1960 (or prior to 1972, see below). We could refine that relationship later to make our fundamental time variable correspond to ephemeris time before 1960 if one of our users has a need for it. I assume we would always want our broken down time to correspond with civil time (UTC or best historical equivalent). The conversion from TAI to UTC from 1960 onward appears in http://hpiers.obspm.fr/eop-pc/earthor/utc/TAI-UTC_tab.html. Before 1972 the UTC adjustment for the irregular rotation of the earth was done by linear transformations. Afterward the adjustment was done by leap seconds. For other remarks about leap seconds (and also another table of them) see http://en.wikipedia.org/wiki/Leap_second. Putting the leap seconds into the code is straightforward, and I would be willing to volunteer for that job. Prior to 1972 we could just use (and document!) a constant offset between our fundamental time variable and UTC. We could refine that relationship later to include the linear transformations epochs back to 1960 if one of our users had need for it. The only real downside to using a TAI-based fundamental time variable for the future is you would have to extend the leap-second table as new leap seconds are announced by IERS. Note these announcements are normally done about six months in advance of the leap second because theory is so far unable to predict the irregular slow-down of the earth's rate of spin on longer time scales than that. On average you expect something like one IERS announcement of a leap second every two years or so. This does constitute an additional PLplot maintenance burden, but only a periodic check of http://en.wikipedia.org/wiki/Leap_second and an addition to the leap second table in the code (if needed) is all that is necessary. Assuming Hazen would be willing to do this, we could add this small task to README.Release_Manager_Cookbook to make sure we stay on top of this for each release of PLplot. 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 __________________________ ------------------------------------------------------------------------- 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
