Questions about mktime()

[Mark Brader]

> > 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.
> 
> OK until Newfoundland tries a 90 minute DST. How about 2 meaning "figure
> it out", e.g., with an environment variable, or an OS call.

That's no good; you can't ask people to check that sort of thing in a
portable program.  The answer is that, when they decide to implement
90-minute DST, you release a new version of your C implementation(*) so
that, during 90-minute DST, tm_isdst is 3.  Or so that tm_isdst is 2, 3, 4
respectively for 60, 90, and 120 minutes.  It doesn't really matter which
-- provided that localtime() and mktime() agree on what the convention is,
and that, if mktime() is handed a positive tm_isdst value that localtime()
wouldn't return, it takes some sensible, documented action that assumes
some flavor of DST.

(*) Better yet, design the implementation in the first place with future
changes of this sort in mind.  The various DST algorithms are best chosen
from a data file anyway, so that they can be changed when someone changes
the DST dates.  So, design that file so that it also includes the mapping
from all known DST offsets to tm_isdst values.  Then when they introduce
90-minute DST, you just add a couple of lines to the file.

Thanks for raising the matter; this is actually an important point.
Even if you don't have to deal with Newfoundland Time, what would you
do if *your* place of abode decided to have 2-hour DST for, say, 2 months
in the summer?  It's happened before...

-- 
Mark Brader			"Computers get paid to extract relevant
SoftQuad Inc., Toronto		 information from files; people should not
utzoo!sq!msb, msb at sq.com	 have to do such mundane tasks."  -- Ian Darwin

This article is in the public domain.