Subject: Re: mktime(3) fails to convert a time in the "spring forward gap"
To: NetBSD Userlevel Technical Discussion List <tech-userlevel@NetBSD.ORG>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-userlevel
Date: 10/09/2002 11:59:35
On Wed, 9 Oct 2002, Greg A. Woods wrote:

> [ On Wednesday, October 9, 2002 at 11:10:03 (-0700), Bill Studenmund wrote: ]
> > Subject: Re: mktime(3) fails to convert a time in the "spring forward gap"
> >
> > On Thu, 10 Oct 2002 itojun@iijlab.net wrote:
> >
> > Is there any standards input on this?
>
> I quoted all I could find on them in my last post to this thread.

Right, I remember seing that, and that it didn't seem to me that it was
obvious who was right or wrong in each case.

> > Because it seems to me that what our
> > mktime is doing is perfectly fine. Those times don't exist on the wall
> > clock, so we shouldn't accept them. Just like we say don't accept
> > 11:09:65.
>
> 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?

> 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. But whouldn't it be better to fix programs
that mess around w/ impossible times?

Take care,

Bill