Subject: Re: mktime(3) fails to convert a time in the "spring forward gap"
To: Bill Studenmund <wrstuden@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: tech-userlevel
Date: 10/09/2002 15:06:32
[ 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" 
>
> On Wed, 9 Oct 2002, Greg A. Woods wrote:
> > 
> > Those wall clock times only don't exist in certain timezones, and as I
> > tried to explain in my previous post an application which tries to
> > calculate offsets using mktime() shouldn't fail in Toronto and yet work
> > in Regina even if it's run at the same local time of day on some certain
> > date.
> 
> 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 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().

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

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