Hello Alan, On Tue, 2008-09-02 at 12:18 -0700, Alan W. Irwin wrote: > 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 appreciate your desire to do this (especially given my understanding of your background), and I will also admit that my suggestion not to do so is partially selfish, in that it would complicate our own application. That said, I think I agree that if we are to handle leap seconds that the preferred route would be a simple lookup table, and one that would only be approximate for the period 1960-1972; implementing the interpolation here would be possible of course, but a headache that may not ever be appreciated or required. I won't dwell on the problem of maintaining an up-to-date lookup table, apart from the fact that it also requires users to regularly update their software. My own experience is that once a user gets something working they are reluctant to upgrade unless there is a compelling reason, with the result that a whole range of versions will be installed around the globe. Even those of us at the development front don't update all software components - only those that we are forced to. My 2-year old Suse system, with most (not all) of its original applications, suits my needs quite well. 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. Of course, your continuous time variable will happily run across that boundary unknowingly and give you the "correct" curve; ignoring leap seconds and converting each timetag would give a slight kink as the same time is plotted twice - or an artificial gap of a second depending on the sign of the leap second which you would wish to avoid by using TAI. However, you now need to put ticks and labels on your axis. Now you have a problem. What you need to do is find the "nice" boundaries (say 30 seconds), divide these into sub-intervals of 5-seconds, and put, say hh:mm:ss labels at 30 second intervals. If the labels are to be :00, :30, ... then the major ticks (and one of the sub-ticks) won't be evenly spaced. Otherwise your labels will drift, e.g., :00, :30, :01, :31. Fixing either of these will be very messy code that will almost never be hit. For longer time intervals the width of a second on the plot is insignificant, so leap seconds are probably not visible and can be ignored anyway. A solution to the user who needs them is then to plot such short time intervals as an XY plot, rather than going through the plplot time handling - though access to documentation and the "new" plplot time routines would enable them to annotate their plot with a UTC time somewhere for reference. A compromise alternative might be to have a TAI/UTC(no_leaps) flag somewhere in the code, function parameters, and/or pltm struct so the user could choose whether to use or ignore leap seconds. In this case I'd suggest they then put up with drifting labels and ticks if they need to worry about leap seconds. Critical to making all this work is a consistent set of routines that START from a broken-down time and CALCULATE a continuous time-since-epoch together with the inverse. If the epoch is not advertised - or comes with a health warning - users will be forced to start from broken-down time and all should be well (meaning there will be no surprises). I'll discuss more with my colleagues here, and I think we all need to work through some of the ramifications of either approach. For plots with lots of datapoints, there will be a calculation overhead in all this that isn't at all visible in the relatively simple plplot examples. Blame it on the Earth. Regards, Steve -- +-------------------------------------------------------------------+ 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
