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 __________________________ ------------------------------------------------------------------------- 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
