mktime

Mark Horton seismo!cbpavo.MIS.OH.ATT.COM!mark
Wed Feb 11 16:18:30 UTC 1987


	  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.

I would prefer to see them rolled into one offset, representing the
offset that applies to whatever time is actually in the rest of the
fields.  My reasoning is that most programs don't care whether DST
is in effect or not, they just want to know what's there.  Such programs
will have to always write code like this:
	tmp->tm_isdst ? (tmp->tm_tzdiff+tmp->tzdstdiff) tmp->tm_tzdiff
instead of the far simpler
	tmp->tm_tzdiff
Also, any program that CREATES a struct tm is going to have to
figure out whether to apply dst or not, a task I don't envy.

If you want to record what the dst offset was, fine, but it should be
an optional component the way isdst is, that is, the tzdiff field can
stand alone without it, and if dstdiff isn't filled in, it doesn't matter.
What I'm suggesting here is that if the time is T+Z+D, then tzdiff would
contain Z+D and dstdiff D (or -D, if you prefer); you were proposing that
they contain Z and D, respectively.

	Mark



More information about the tz mailing list