Hi Steve: Since this is a broader topic, I have changed the subject line.
On 2008-09-02 02:14+0100 Schwartz, Steven J wrote: > Alan, > Your approach in example 29 is to use the TZ environment variable to trick your computer into thinking that it is in a UTC timezone. This doesn't work on all platforms, hence your ifdef for Windows. To explain some background here, I was following the POSIX-compliant approach recommended as an alternative to timegm by the timegm man page on Linux. That said, I think we agree our example programs should demonstrate the best methods if at all possible, and I am not particularly happy with this POSIX-compliant method for obtaining UTC time in seconds since the Unix epoch from broken-down time. For one thing, it appears not to work for Jerry's Mac OS X platform for unknown reasons, and you have mentioned some other reasons as well which I largely agree with. > An alternative approach, which I offered in a (small) patch several weeks back, is essentially a private and totally portable implementation of timegm, which I called mktimeutc, that lives inside plplot - but which could/should be made available to the end user. This guarantees that the plplot time axis handling will behave itself and that the end-user has a consistent way to construct and break-down a calendar time. We have dealt with a similar issue recently with random numbers, and in the end we decided to embed our own small high-quality random-number generator into our C library with that generator available for each of our language bindings to give us uniform results for all languages and as a general service to our users who often do need access to high-quality RNG's. I think we should follow a similar approach with UTC, but aim for the absolutely best algorithm possible with none of the limitations of the POSIX algorithms. If no core developer objects to that idea, then I have some ideas about how this should be implemented. (1) Rename mktimeutc as pltimeutc to be consistent with the rest of our names. (2) I haven't actually looked at that routine yet, but I think we should carefully review the argument list and what is returned. I would favour representing broken-down time as yyyy, mmmm, dddd, hhhh, mmmm, ssss, where the first 5 arguments are integers and the last double precision. And I think we should store the result (seconds since the Unix epoch) as two additional double precision arguments where the first one represents the integer number of seconds since the epoch (and which is therefore exact for a huge range of epochs) and the second one a fractional remainder. As a result this would be a void function. (3) I think we need a plutctime void function as well to be the exact inverse of pltimeutc with essentially no range limitation (unlike gmtime) and using the same argument list (perhaps in different order) as pltimeutc. Do you have access to such code, and if so, would you be willing to donate it to PLplot? (4) Thoroughly test plutctime to make sure it delivers the same result as gmtime within the latter's range limitations, and thoroughly test pltimeutc to make sure it reliably delivers the inverse of plutctime. How do you handle the leap-second problem for the current mktimeutc? Do you ignore leap seconds altogether (which is probably not a good idea) or do you have a table of leap seconds within the routine? (5) Assuming pltimeutc and plutctime pass all our tests, make them part of our public C library API and make them available for each of our language bindings so that we no longer have to adopt hard-coded constants for example 29 for any language and also as a service for our scientific users who deal with plotting of time series. Before any core developer complains about reinventing the wheel, I am concerned about that issue as well, but I think our recent experience with example 29 shows that the C library does a horrible job of dealing with UTC, and that is true for some of the other computer languages as well. Thus, I think it is a good idea for PLplot to step forward to fill this gap uniformly for all our language bindings to the benefit of our users who are concerned with plotting time series. 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
