[ On Sunday, October 6, 2002 at 20:34:19 (-0400), der Mouse wrote: ]
> Subject: Re: mktime(3) fails to convert a time in the "spring forward gap"
>
> > It seems NetBSD's (and FreeBSD, at least 4.7-RC's) mktime(3) fails to
> > convert a time in the "spring forward gap".
> 
> If there is a standard that specifies this, I think we should follow
> it.  But absent that, I think it's the test that's broken, not our
> mktime; I see nothing wrong with failing when asked to convert a time
> that doesn't exist.

I don't know if there's a standard which specifies the correct behaviour
in this case or not.  The Single UNIX Spec. v3 has this to say on the
topic:

     [Option Start] A positive or 0 value for tm_isdst shall cause
     mktime() to presume initially that Daylight Savings Time,
     respectively, is or is not in effect for the specified time. A
     negative value for tm_isdst shall cause mktime() to attempt to
     determine whether Daylight Savings Time is in effect for the
     specified time.

     The relationship between the tm structure (defined in the <time.h>
     header) and the time in seconds since the Epoch is that the result
     shall be as specified in the expression given in the definition of
     seconds since the Epoch (see the Base Definitions volume of IEEE
     Std 1003.1-2001, Section 4.14, Seconds Since the Epoch) corrected
     for timezone and any seasonal time adjustments, where the names in
     the structure and in the expression correspond.  [Option End]

Since a time may be in a spring forward gap in one timezone and not in
another I would tend to think that this might suggest mktime() should
return a value which represents either the beginning or end of the gap
if a timezone is given where the time in question is in a spring forward
gap.

However SuSv3 also says this about error handling:

     The mktime() function shall return the specified time since the
     Epoch encoded as a value of type time_t.  If the time since the
     Epoch cannot be represented, the function shall return the value
     (time_t)-1.

and I can understand an interpretation suggesting that a wall-clock time
in the gap cannot be represented as a time in seconds since the Epoch.

The practical application might be some tool like at(1) which allows the
user to specify an offset from some time.  One way to implement a delta
of a complex offset specification might be to convert both times using
mktime() and then calculate the difference in the resulting time_t
values.  Now if the offset happens to put one end of the period into a
spring forward gap then why should the user be essentially told that the
calculation of this offset is only valid if it's done in certain
timezones (eg. in UTC, or Saskatchewan)?  If I'm not mistaken you can't
even try to make such an implementation smarter by first converting the
time specifications to UTC because doing so in complex cases will still
require use of mktime().

(I really wish DST had never been invented -- what a stupid idea!  We
should just all live by the Standard Time based on our longtitude, i.e.
in the originally specified one-hour jumps.  City folk wouldn't need DST
if politicians had not got involved and shifted all the boundaries so
wildly about to suit their needs.  The only thing that makes it bearable
for me is that my computer knows all the rules for most of the places in
the world and it always shows me the right time as long as I tell it
where I am!  ;-)

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>