mktime() failures under PCTS testing

Paul Eggert eggert at twinsun.com
Wed Mar 23 03:54:12 UTC 1994


   Date: Tue, 22 Mar 94 19:03:37 EST
   From: ado at elsie.nci.nih.gov (Arthur David Olson)

   The time zone package is assuming that the "mktime" call is asking
   a question such as...

	   If US DST rules are in effect and I'm in the Eastern US, when, on
	   April 3, 1994, will a wall clock show 2:30 a.m. (irrespective of
	   whether it is or isn't daylight saving time)?
   ...and the "-1" answer is the package's way of saying...
	   There is no such time!

   If someone has the relevant wording from the current version of the
   relevant standard(s) on what to do here, I'd love to hear from you.

The relevant standard (i.e. the C standard) is obscure in this area.
The closest that it comes to addressing the problem is the ANSI C
Rationale, section 4.12.2.3 (ANSI X3.159-1989 page 109), which says:

	If this field [tm_isdst] is set to -1 on input, one truly
	ambiguous case involves the transition out of daylight savings
	time.  As DST is currently legislated in the USA, the hour
	0100-0159 occurs twice, first as DST and then as standard
	time.  Hence an unlabeled 0130 on this date is problematic.
	An implementation may choose to take this as DST or standard
	time, marking its decision in the `tm_isdst' field.  It may
	also legitimately take this as invalid input (and return
	(time_t)(-1)).

What the Rationale _doesn't_ say is that there are other truly
ambiguous cases, e.g. the transition _into_ daylight savings time.
The general rule is that mktime wraps out-of-range inputs.  If
mktime's input is an unlabeled time like 02:30 that does not exist,
it's ambiguous as to whether the implementation should wrap this
out-of-range input to 01:30 or to 03:30.  But by analogy with the
Rationale, it seems plausible that in this case an implementation may
choose 01:30 or 03:30 (setting tm_isdst accordingly), or it may also
legitimately take this as invalid input and return (time_t)(-1).

Now all this is complicated by the fact that the ANSI C standard has
been superseded by ISO C.  ISO C did not change the standard itself,
but dropped the Rationale.  Furthermore, there is a series of
unpublished C interpretation rulings that may bear on the issue.
But from the information that is public, I would say that PCTS is
broken and should get fixed.

Of course, if PCTS is pickier than the standard requires, we don't
have to change mktime to agree with PCTS.  But it might be more
consistent to do so, since (according to my reading of the code)
mktime does not yield -1 for the case cited in the Rationale.  It's
certainly a bit unnerving that on a leap-forward day, mktime treats
01:59:60 like 03:00:00 (and 01:59:61 like 03:00:01!), but it treats
01:59:62 as an error.



More information about the tz mailing list