[ On Wednesday, October 9, 2002 at 16:02:35 (-0400), Andrew Brown wrote: ]
> Subject: Re: mktime(3) fails to convert a time in the "spring forward gap"
>
> >If you want an hour after a given time, isn't it better to get a time_t
> >and do the math on it?
> 
> almost.

I'd say "almost never".  :-)

(at least not when you're trying to deal with "logical" offsets against
local wall-clock time in some sensible manner)

> suppose you wish to add a day.  simply adding 86400 won't get
> the right answer either, because when you skip an hour due to daylight
> savings, a day is only 82800 seconds long.

That's one of the situations you can get into for sure!  There are many
more like it.  Any time offset, even just adding or subtracting one
second, can have the same problem.

> imho, any application that wants to muck with time like this *NEEDS*
> to know that daylight savings time might become an issue and deal with
> it accordingly.  it *CAN'T* simply pretend that wall clock time is
> continuous (if it insists, make it do the work in utc and perhaps
> convert to the local time zone later).  whether any two applications
> do this the same way is up to the application.

Therein lies the problem.  The DST magic is these days intentionally all
hidden withing the bowels of mktime() et al.  An application cannot know
when DST might be an issue without digging into the guts of mktime()
itself and parsing the tzcode data libraries directly.  Maybe some of
those tzcode internal interfaces could be made public, but on the other
hand if mktime() just did the right thing when (sensible) arithmetic is
done to the struct tm fields and if it did not blow up just because the
result happens to land in a DST gap, then those tzcode interfaces could
remain private and no applications programmers would have to learn new
API tricks and hooks either.

I really do trust Paul Eggert to have thought through these issues quite
deeply in deriving the fix for his GNU libc implementation.  He's had a
good deal of experience dealing with timestamps and time calculations.
He's also apparrently the one who suggested the mktime() test be
included in autoconf.

-- 
								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>