Alan,
I spent some time looking for a nice portable solution and failed to find one. This was the best I could come up with. I'm glad you've independently come to the same conclusion. I will add checking the java and octave versions of example 29 to my to-do list. Andrew On Fri, Jul 11, 2008 at 08:18:39AM -0700, Alan Irwin wrote: > On 2008-07-10 14:57-0700 Alan W. Irwin wrote: > > > Hi Andrew: > > > > Jerry's recent commit message for Ada example 29 inspired me to investigate > > further, and indeed the fortran (and presumably the rest of the non-C) > > examples are an hour out compared to the C example. > > > > For example, in python > > > > calendar.timegm((2005,12,1,0,0,0)) > > > > returns > > > > 1133395200 > > > > which is consistent with Jerry's recent fix for the Ada example, but > > an hour inconsistent with > > > > f77/x29f.fm4: tstart = 1133398800 > > f95/x29f.f90: tstart = 1133398800 > > java/x29.java: tstart = 1133398800; > > > > > > Part of the problem here is the time code in example 29 is just too > > complicated. mktime has a local timezone offset which must be compensated by > > the offset logic which is difficult to follow without doing a lot of man > > reading. I think that logic is actually working and only the constants in > > the non-C examples are out by an hour (as shown above), but to clear up all > > confusion I suggest we make the time code in the C example 29 much simpler > > by working with UTC from the start. The way to do that is to use the POSIX > > equivalent of the Linux timegm function (written in terms of mktime and > > tzset, see the Linux timegm man page) for maximum portability. > > > > Also, for the python example we should directly use calendar.timegm (as > > above). There might be something equivalent to timegm in java as well. > > > > Andrew, if you agree to the above straightforward changes I should be able > > to do them (except for finding a timegm equivalent in java) myself. > > Hi Andrew: > > Never mind. I have now looked more closely at your example 29 code, and I > actually like it better than the fiddling with the TZ environment variable > suggested by the Linux man page for timegm since I am not sure how that > would work on Windows. I have now documented your code some more and have > also changed the casting a bit to be more consistent. I have also changed > the C++, f77, f95, and Python versions of the code so they (along with > Jerry's recently changed Ada examples 29) all give consistent results. > For the Python version I changed to using calendar.timegm((2005,12,1,0,0,0)). > > I leave the octave version (which gives consistent results but which > probably needs better documentation and/or moving to an octave equivalent of > timegm) and java version (which currently gives inconsistent results and > which probably needs moving to a Java equivalent of timegm) to you. > > Could somebody with Windows access try example 29? That example only uses > POSIX compliant time functions like mktime and difftime, but I am not sure > whether the Windows C library provides those or not (or even supplies them > under a different name). > > 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 > __________________________ > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > Plplot-devel mailing list > Plplot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plplot-devel > ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
