On 2008-07-18 01:22-0000 [EMAIL PROTECTED] wrote: > Hi, > > > Alan W. Irwin wrote: >> On 2008-07-17 22:51+0100 Andrew Ross wrote: >> >>> 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. >> > > There was daylight saving in effect in the UK on 1/1/1970. The UK experimented > with continuous daylight saving from October 1968 till September 1971 > (known as British Standard Time), so in this case toff = 3600 is correct.
Thanks very much, Terrence, for that bit of history which is confirmed in the body of http://en.wikipedia.org/wiki/British_Summer_Time There just doesn't seem to be any end to the way politicians fiddle with "daylight savings", but that is the start of my own personal rant on that subject so I will not take that further here. The logic of example 29 demands that toff be calculated for the same hour offset as in effect for December 1 2005 UTC for each user's locale. Andrew, can't we accomplish that goal by calculating toff _after_ tstart is calculated? I think to accomplish that you only have to start the toff calculation with t0=tstart. For some locales, the local December 1 2005 could be 12 hours (or is that 13 hours?) ahead of or behind December 1 2005 UTC, but the t0=tstart idea should work unless there was a change in "daylight savings" status in that small interval of time in some locale. Of course, a much cleaner solution would be to use timegm (an implementation using the POSIX functions setenv, getenv, tzset, and mktime is given by the GNU/Linux man page, see, e.g., http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/timegm.3.html), but I am not sure that (a) getenv and setenv are available for Windows, and (b) if so whether TZ is a meaningful "environment variable" on that platform that actually affects the results returned by mktime. So I think the above t0=tstart idea is good enough unless someone will do the required Windows research to see if the POSIX way of calculating the equivalent of the GNU/Linux timegm would actually work on the Windows platform. 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
