On Wed, 9 Oct 2002, Greg A. Woods wrote:

> [ On Wednesday, October 9, 2002 at 11:59:35 (-0700), Bill Studenmund wrote: ]
> > Subject: Re: mktime(3) fails to convert a time in the "spring forward gap"
> >
> > But how could something HAVE those times as local time-of-day on those
> > dates?
>
> It doesn't have them -- it tries to create them by doing arithmetic on
> the struct tm fields to try and calculate wall-clock time for some
> offset from some other time which it does "have".  I've written several
> programs which worked that way.

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. Do the standards say anything about this?

> > > I have not yet looked at GNU's libc (which has apparently had a fix for
> > > the past four years or so), but I suspect the solution they use is to
> > > simply convert inter-gap times to end/beginning-of-gap times.
> >
> > Well, that'd be one option.
>
> See my next post containing Paul Eggert's fix for his GNU Libc mktime().

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

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

If you want an hour after a given time, isn't it better to get a time_t
and do the math on it?

Take care,

Bill