Date: Thu, 11 Apr 2002 11:23:30 +0100 From: Brian Somers <brian@freebsd-services.com> To: Sean Chittenden <sean@chittenden.org> Cc: Brian Somers <brian@freebsd-services.com>, freebsd-standards@FreeBSD.org Subject: Re: mktime() doesn't fix deadzones... Message-ID: <200204111023.g3BANUOF032971@hak.lan.Awfulhak.org> In-Reply-To: Message from Sean Chittenden <sean@chittenden.org> of "Wed, 10 Apr 2002 12:54:09 PDT." <20020410125409.B34587@ninja1.internal>
next in thread | previous in thread | raw e-mail | index | archive | help
> [please trim current@ from the CC list on reply]
>
> > IMHO the SQL code you quote in the PR should fail with an ``invalid
> > time'' error.
>
> There's some truth to that... but Apr 7th 2am -8:00 isn't an invalid
> datetime. It isn't correct, Apr 7th 3am -7:00 is the correct time,
> but they're identical because UNIX time never sees any of these
> kludgey timezone problems.
I think that ``Apr 7th 2am PST'' and ``Apr 7th 2am PDT'' are both
invalid times. The PDT/PST bit suggests that they've already been
``normalised''.
> > Personally I like the fact that mktime() returns -1 - it allows
> > date's -v option to act sanely, although I must admit it was a PITA
> > to get right.
>
> I like that mktime() returns -1 for invalid times, but I don't think
> Apr 7th @2am-8 is an invalid time. Not correct, but not invalid
> either.
>
> > The really big question is, how can you ``fix'' mktime() ?
>
> For now, tm->tm_hour +=3D 1 is a reasonable solution, IMHO. From the
> testing done by the PostgreSQL folks, I gather that most other *NIX's
> automatically account for this border condition and change the passed
> in time structure.
>
> The alternative seems to me would be to have it return -1 on 2am and
> then leave it up to the application writer to detect this and attempt
> a 2nd call w/ tm->tm_hour incremented. The only caveat to that being
> that I'm not sure if all daylight savings shifts are 60min.
I believe there are other shifts. AFAIR wollman told me that in an
email a few years ago.
In the date -v case, this is dealt with more sensibly than if mktime()
just added an hour.
> Last thing to think about in favor of having mktime() handle this,
> October 40th automatically gets changed to November 9th already.
> Having mktime() adjust things for timezones as well as dates doesn't
> seem too unreasonable.
If mktime() adjusts the passed date, it makes it difficult for
applications to deal with it - When I say 2:30, and that falls in a
2:00 - 3:00 gap, do I mean 1:30, 3:30, 1:59 or 3:00 ? This really
depends on the application.
[.....]
--
Brian <brian@freebsd-services.com> <brian@Awfulhak.org>
http://www.freebsd-services.com/ <brian@[uk.]FreeBSD.org>
Don't _EVER_ lose your sense of humour ! <brian@[uk.]OpenBSD.org>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-standards" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200204111023.g3BANUOF032971>