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 [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
