Newsgroups: comp.std.c
Path: utzoo!sq!msb
From: msb@sq.sq.com (Mark Brader)
Subject: Re: Questions about mktime()
Message-ID: <1991Jan23.052427.17720@sq.sq.com>
Organization: SoftQuad Inc., Toronto, Canada
References: <1991Jan18.225155.7310@druid.uucp> <1991Jan20.205039.7056@sq.sq.com> <1991Jan21.115249.24661@watmath.waterloo.edu>
Date: Wed, 23 Jan 91 05:24:27 GMT
Lines: 46

I wrote:
| The rule is that if tm_isdst is positive, you have to assume Daylight
| Saving Time; if zero, you have to assume Standard Time; if negative, you
| have to "attempt to determine whether Daylight Saving Time is in effect
| for the specific time".
and then referred to "adjust[ing] the computed time by 3600 seconds".

This drew the followup:
> Now what do we do with the double DST that Newfoundland has/had?

It's "had", by the way; they only tried it for (the usual Daylight
Saving Time period during) one year.

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.

I'd also have it that mktime() would assume that a time specified with
tm_isdst == 1 was 1 hour advanced, and one with tm_isdst >= 2 was 2 hours
advanced.  It is *not* clear to me that this would be Standard-conforming,
as the actual wording about mktime() and tm_isdst is essentially just
what I said above -- and even that is only in a footnote, thus not
technically part of the Standard.  But I think it is in the spirit of
the Standard's intent, and if this approach was submitted for an
Interpretation Ruling, then I'd expect it to pass.

During the public reviews, I requested the addition of language to
cover this situation, something along the lines of "an implementation
may define different positive tm_isdst values associated with different
Daylight Saving Times that may be in effect."  This was rejected, as I
recall, on the grounds that "the Committee feels that this is clear
enough as is."

Of course, the other tricky thing for the implementer is that the
algorithms and data structures used have to be able to allow for
multiple different DSTs.  But there's nothing intrinsically difficult
about that; the only problem is thinking of it in the first place.
-- 
Mark Brader		    "It can be amusing, even if painful, to watch the
SoftQuad Inc., Toronto	     ethnocentrism of those who are convinced their
utzoo!sq!msb, msb@sq.com     local standards are universal."	-- Tom Chapin

This article is in the public domain.