Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!sdd.hp.com!elroy.jpl.nasa.gov!ncar!hsdndev!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: Questions about mktime()
Message-ID: <14952@smoke.brl.mil>
Date: 23 Jan 91 23:51:40 GMT
References: <1991Jan20.205039.7056@sq.sq.com> <1991Jan21.115249.24661@watmath.waterloo.edu> <1991Jan23.052427.17720@sq.sq.com>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 17

In article <1991Jan23.052427.17720@sq.sq.com> msb@sq.sq.com (Mark Brader) writes:
>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.  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.  Note that we have a similar
situation with certain U.S. communities that passed local ordinances
exempting them from the national DST laws.  I feel that such variations
are better dealt with via timezone name strings than special conventions
about the values of tm_isdst.