seismo!nbires!vianet!devine seismo!nbires!vianet!devine
Tue Feb 10 21:45:21 UTC 1987

  This message is on the mktime() function and a new struct tm.

Mark Horton says:
> If we're to view mktime as a general-purpose converter from struct tm
> to time_t, there's a gotcha waiting:  struct tm doesn't contain any
> time zone information (the isdst flag doesn't help) and hence this
> conversion is ambiguous, unless you assume the local time zone or gmtime
> or some such thing.  That's not a good assumption to make.
> In my implementation, I added two fields to struct tm, for the hours and
> minutes in the time zone which resolved the ambiguity.

kre says:
> So, I would suggest a new function to handle mktime() with a supplied
> zone, which would look at extra info in the struct tm.
> So, I would suggest a single field that contains the offset in seconds
> from GMT.

  To repeat a suggestion I made a couple of months ago, let's extend
'struct tm' with fields to reduce the ambiguity.  Consider that if someone
hands you a 'struct tm' without providing usage information, it is worthless
because you don't know its base.  The same argument applies to many other
date/time representation.

  The new, improved 'tm' has two offset fields:
	 struct tm {
		 /* all current fields */
		 time_t tm_tzdiff;
		 time_t tm_dstdiff;
		 char*  tm_tzname;

  One would add in the tm_dstdiff if tm_isdst is true, otherwise
only the tm_tzdiff is added.  The mktime() call need not be concerned
with translating time zones to hour:minute offests from UT, it only
needs to churn through the calculations for the structure members.

  Ron Tolley suggested that the tm_tzdiff and tm_dstdiff values can
be rolled into a tm_tzadj.  I prefer the flexibility offered with the
two separate values.  Calculations on the 'struct tz' can more easily
deal with the DST boundary conditions if both values are distinct.

Bob Devine

More information about the tz mailing list