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