mktime

[seismo!nbires!vianet!devine]

  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