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 <firstname.lastname@example.org>
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 email@example.com 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
But how could something HAVE those times as local time-of-day on those
> 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?