On 2008-08-03 15:56+0100 Steve Schwartz wrote: > Dear Plplot-devel, > > I attach a patch that immunizes plplot from the peculiarities of C's > mktime function, that arise because mktime requires input in localtime. > The various recipes to calculate offsets from local time to utc, such as > those in example x29, are not foolproof or portable. I have not explored > the equivalent timegm function that I've seen in one of the plplot-devel > threads, but some of them still rely on mktime and then attempt to > adjust the result.
Hi Steve: Thank you for your interest in improving PLplot's treatment of time. I was involved in time research in the late 90's (calculation of time ephemerides for the Earth where I was aiming for sub ns numerical accuracy over millenia) so I have an interest in making sure PLplot's treatment of time is the best possible. I fully agree with your comments about the peculiarities of local time so it should be avoided completely. Have you looked at our recent svn trunk revision 8530 of x29c.c which temporarily sets TZ to the null string to avoid those peculiarities? One concern with that approach is what to do for Windows platforms, but do you think there would be any other concerns? Note, we haven't yet tried that TZ approach for the calls to mktime in src/pldtik.c, but that is one possible approach to avoid the peculiarities of local time there. Thus, your comments on applying the current approach for example 29 to our core library would be appreciated. We may end up just adopting your patch (for which many thanks, by the way), but I want to make sure we are not missing a simpler solution to the problem. Ephemeris calculations have to contend with the issue of the best way to represent time over millenia while minimizing rounding errors. IIRC, the JPL ephemeris (upon which my time ephemeris research was based) solved the problem by representing time (in Julian days) as two 64-bit floating point numbers. The first one was exact since it represented the integer portion of the Julian date, and the second represented the fractional part to something like 1 part in 10^17 which translates to an error of roughly 0.001 ns at worst. I haven't had a chance to look at your patch yet, but I am curious about how you solved this same "time representation" problem. 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
