Date: Thu, 30 Apr 87 21:34:04 EDT From: mark@cbpavo.mis.oh.att.com (Mark Horton) Message-ID: <8705010134.AA06737@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). kre