Questions about mktime()

[Mark Brader]

> > If the time was actually during the hour that's
> > skipped when the clock moves forward, then you were given a "calendar
> > time that cannot be represented" and you should return (time_t)-1.
> 
> I don't think this is right.  My understanding is that a "calendar
> time that cannot be represented" refers to the case where the resulting
> return value from mktime() would be outside the range of the time_t type.

Well, it certainly does refer to that case; the question is whether it
refers to the skipped-hour case as well.  I would argue that it does,
on the grounds that an impossible time, ipso facto, cannot be represented.
But it might also be argued that an impossible time is merely a special
case of one of the values being out of range, and therefore must be
handled without a -1 being returned.  The wording referring specifically
to the "calendar time" hints at the latter interpretation, but I don't
think this is conclusive.  A ruling would be a good idea.

> > The ambiguous times that are repeated when the clock moves backwards are
> > also a problem, but here the Standard is silent and it would seem you're
> > free to choose either option if one of these times was specified with
> > tm_isdst negative.
> 
> I agree that either result is acceptable in this case, but the standard
> isn't really silent on this.  It says,
>     "A negative value for tm_isdst causes the mktime function to attempt
>     to determine whether Daylight Saving Time is in effect for the
>     specified time."
> The words "attempt to determine", in my view, are there specifically to
> cater for the problems at change-over times. ...

Certainly not.  Systems that don't know about clock changes at all, where
localtime() will return tm_isdst negative, are also catered for by this.
My assumption was that this was intended to refer *only* to such systems.

> From the user's
> point of view, getting a sensible return value is greatly preferable
> to getting (time_t)-1.

I disagree.  From *my* point of view as a user, if my system knows about
DST, then my giving tm_isdst<0 to mktime() is an assertion that the time
I gave was wall clock time, and if I give it a time that doesn't exist,
I want it to tell me so.  To me it's just like a division by zero.


| > The Standard says that "the local time zone and Daylight Saving Time
| > are implementation-defined" and makes no distinction between different
| > positive values of tm_isdst.  If I was an implementer having to deal
| > with Newfoundland, I'd be inclined to say that localtime() would assign
| > 1 to tm_isdst for a 1-hour advance, and 2 for a 2-hour advance.  This is
| > clearly Standard-conforming.
| 
| There is no need to do this, if it is clear what the DST rules are (for
| all relevant time periods) for the given local time zone.

It appears to be Standard-conforming to used a single positive tm_isdst
value, but you get improved functionality by using multiple such values,
so I would expect high-quality implementations to do so.  Still considering
Newfoundland, they had 2-hour DST in 1988 and 1-hour DST in other years.
Suppose that the applicable time is Newfoundland Time, and time_t t
contains a calendar time in the summer of 1988, and I say:

	struct tm s = localtime(t);
	s.tm_year++;		/* advance by one year */
	s.tm_isdst = -1;	/* negative --> "please determine DST" */
	t = mktime(s);

Then I expect t to have increased by (365*24-1)*3600, allowing for the
change in DST rules between the two years.  On the other hand, if I omit
the statement "s.tm_isdst = -1;", then I expect t to have increased by
(365*24)*3600.  This is analogous to the behavior that the standard
requires to occur if, rather than s.tm_year++, I did s.tm_mon++ and
crossed a clock change in doing so.  But if the implementation uses a
single positive tm_isdst value for different DST's, it can't behave
that way.

| I would say
| that the time zone should really have been given a different name if
| one portion of it required local clocks to be set differently from
| other portions of the "same" time zone. ...

Well, clearly, however you tell your system which time zone is to be used,
you also have to tell it in some way what DST rules apply.  Besides the
examples of places that don't use DST, or didn't use it during certain
years, there are also places that used it for abnormal periods during
certain years, like most of the USA in 1974.  And part of Newfoundland is
in Atlantic Time, and thus differed from the rest of the Atlantic Time
zone during the DST period during 1988.  It's not obvious to me that the
time zone name is the best way to pass such information, but it's certainly
one reasonable way.

Oh, yes, for curious foreigners: Newfoundland Standard Time is 3 hours
30 minutes west of UTC/GMT; Atlantic Standard Time, 4 hours west.
-- 
Mark Brader			"[This computation] assumed that everything
SoftQuad Inc., Toronto		 would work, a happy state of affairs found
utzoo!sq!msb, msb at sq.com	 only in fiction."	-- Tom Clancy

This article is in the public domain.