[ On Wednesday, October 9, 2002 at 12:42:43 (-0700), Bill Studenmund wrote: ]
> Subject: Re: mktime(3) fails to convert a time in the "spring forward gap" 
>
> I also thought that, from your previous post, that there was a "right" way
> to do that; to select a time at a given offset, you tweak certian fields
> of the time.

Yes, that's how I've always done it.

> Do the standards say anything about this?

Only about what ranges of values are valid for each struct tm field.

> I saw the post, and I don't understand mktime well enough to know if it's
> ok.

It seems to be OK from the discussions I've read about it.

Of course that patch is against Eggert's implementation in GNU Libc....

> Here's the scenario. We're in a timezone where we spring forward at 0200,
> so 02XX doesn't exist.
> 
> How does this patch deal with the cases of both taking 0130 and adding an
> hour, and taking 0330 and subtracting an hour? If I understand what it'll
> do, it will be ok for 0130 + an hour, but get 0330 - an hour wrong.

But that's not "an hour wrong".  That's exactly what ctime(&time(NULL))
will return in one hour from that 01:30 local time since there is no
02:30 for the presumed timezone on the day of the gap.

> > >  But whouldn't it be better to fix programs
> > > that mess around w/ impossible times?
> >
> > That's just simply not possible.  They're not broken in non-DST timezones.
> 
> No, they're broken by design. They are trying to do math on things that
> don't do math well; timezones have the concept of non-existant times,
> regardless of whether or not a given timezone has DST or not.

How can such applications be "broken by design"?  They cannot, by
definition, have any concept of how the DST rules for for any given
timezone work.  All that stuff is necessarily and thankfully hidden from
view by mktime() et al.  Doing math on struct tm fields is very common
practice in my experience.

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