On Thu, Jul 17, 2008 at 07:47:51PM -0700, Alan Irwin wrote: > 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.
Ah! I'd forgotten about that experiment. > 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. I'll try this out. I think it would work for the example but is not bullet proof around the transition times as you say. > 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. The other solution is just to keep everything in local time. The actual values of tstart would then differ between timezones but the output should be identical as long as all the calculations are done in the local time zone. This is probably the "correct" way of doing things. The user would probably expect the local time zone to be used for labels etc unless they specify otherwise by changing the timezone. This would dramatically simplify the examples. 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
