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>