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).
Actually, while checking the various languages I found a problem with my approach. Obviously my linux system is missing daylight saving information for 1970. Calling t1 = 0; tm = *gmtime(&t1); t2 = mktime(&tm); toff = (PLFLT) difftime(t1,t2); returns 3600 for toff at the moment, and not 0 as it should (I'm in the UK). There should be no daylight savings for 1st January so the local time is equivalent to UTC. I presume the error is because it is using the current daylight saving settings in the absence of any more detailed information. Setting TZ="UTC" before calling the function makes everything work as expected. Alan, perhaps your solution of providing an implementation of timegm (if not available) or meddling with TZ explicitly is the best after all. This is not neat either, but should be portable and more reliable. I have rewritten the java example to set the timezone to UTC (there are functions for doing this is java) so this should provide a benchmark to test against. Andrew ------------------------------------------------------------------------- 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
