Fri May 1 19:32:59 UTC 1987
Date: Thu, 30 Apr 87 21:34:04 EDT
From: mark at cbpavo.mis.oh.att.com (Mark Horton)
Message-ID: <8705010134.AA06737 at cbpavo.MIS.OH.ATT.COM>
How? deadline is a time_t (GMT) and so is time(0).
Simple, though its easier to explain if we use a 2 hour increment
rather than one, 1 hour increments get into problems of tm's
falling into improosibe time_t's (no legal conversion).
Consider that the fragment of code is being run at 01:30 on
October the X, which happens to be the (northern hemisphere)
day that daylight saving switches on.
Taking some liberties with correct C code (missing out casts,
declararions & such) ..
now = time(0); now = N; (for some N)
tm = *localtime(&now); tm.tm_hour = 1; tm.tm_min = 30;
tm.tm_hour += 2; tm.tm_hour = 3; tm.tm_min = 30;
later = mktime(&tm); later = N + 60; /* !!! */
this is because at N+30 tm.tm_hour increased by 1, while
time(0) increased by nothing.
The problem with all this is that mktime is supposed to be the
inverse of localtime, if it was the inverse of gmtime, or if it
had a zone parameter, then this kind of thing could be made to
work. But then mktime would be useless for more common functions,
especially that of hiding the timezone & dst rules from the application.
Assuming that you have a version of ado's localtime somewhere (the
recent mod.sources posting will do), you can easily test this by making
a faze zone name, where DST changes just about an hour ahead of whatever
time it is now, setting TZ to that zone, and then watch it happen (use
timelocal for mktime).
More information about the tz