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.
> toff was -28800 (- 8 hours) here which makes sense since in January 1970
> (any winter, for that matter unless the politicians really get crazy) my
> local time is 8 hours less than Greenwich time. So, Andrew, I agree with
> your conclusion that you have a locale bug (missing information about 1970)
> for the particular platform you were trying.
>
> You might want to print out toff on additional platforms to see whether that
> locale bug is common or not.
>
> Also, what happens if you specify t1 for January for a range of years from
> 1900 to 2008? It would be interesting if toff were non-zero only for 1970.
>From Microsoft MSDN pages
Microsoft VC mktime returns -1 for any GMT time prior to midnight 1/1/1970.
Further "after an adjustment to Greenwich Mean Time (GMT), mktime handles
dates from
midnight, January 1, 1970, to January 19, 3:14:07, 2038. This adjustment may
cause mktime to return -1 (cast to time_t) even though the date you specify
is
within range. For example, if you are in Cairo, Egypt, which is two hours
ahead
of GMT, two hours will first be subtracted from the date you specify in
timeptr;
this may now put your date out of range."
Further Google indicates that in some (older?) linux distributions, their
mktime also
returns -1 for dates prior to 1970.
>
> Our local LUG had a report from one of its members recently that the date
> command was giving him screwy results for the last second in 1969. (He
> happened to be making a table of date results for the last second of every
> year since 1900.) It turned out he had an old CENTOS distro with some
> time/locale issue and everybody else (including those with more modern CENTOS)
> got the right answer (-1).
Given the google result, they maybe just returning -1 to indicate the date is
not an
accepted date. :-)
>
> So it is quite possible you have found a time/locale bug specific to your
> particular platform.
>
Note it is probably worth testing if the return value from mktime is -1 and
printing a
warning / error message.
Kind regards
Terrence
__________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at
Yahoo! http://uk.docs.yahoo.com/ymail/new.html
-------------------------------------------------------------------------
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
