Steve, Alan, I entirely agree that the only sane, cross-platform and cross-language way of dealing with the timegm (and possible gmtime) problem is to add our own implementation. This is relatively straightfoward and I can see no reason not to. The bigger question is whether we carry on using strftime. Systems with limitations in gmtime (like no negative values for time_t) are likely to be limited with respect to strftime as well. Replacing and maintaining this is a much bigger job though.
Andrew On Mon, Sep 01, 2008 at 10:59:23PM -0700, Alan Irwin wrote: > 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 > ------------------------------------------------------------------------- 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
