On 2008-07-18 10:12+0100 Andrew Ross wrote: > > On Thu, Jul 17, 2008 at 07:47:51PM -0700, Alan Irwin wrote: >> [...]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.
In astronomy (and probably in many other disciplines) you have to coordinate time series of observations taken from all over the world so UTC (or the equivalent in Julian date) is axiomatic, and you never plot or report observations in local time. So I admit to being strongly biased toward examples that are presented in UTC, and I am willing to work a bit to get that right. In C and C++ it takes only a few function calls to implement a POSIX equivalent of timegm that should be good for any Unix platform version of the C library. So I have done that for both the C and C++ versions of example 29 (revision 8530). This should work on at least every Unix platform, and its possible it might work on Windows as well, but that will take some testing by our Windows developers. For the Windows case for now, I have done what we have already done for Fortran which is simply use the known tstart. I have compared all the results, and they are equivalent on my system, and each of our developers (whether Unix or Windows) should now also get this result regardless of their locale. 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
