Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 10 Apr 2002 12:54:09 -0700
From:      Sean Chittenden <sean@chittenden.org>
To:        Brian Somers <brian@freebsd-services.com>
Cc:        freebsd-standards@FreeBSD.org, current@freebsd.org
Subject:   Re: mktime() doesn't fix deadzones...
Message-ID:  <20020410125409.B34587@ninja1.internal>
In-Reply-To: <200204101233.g3ACXaOF052655@hak.lan.Awfulhak.org>; from "brian@freebsd-services.com" on Wed, Apr 10, 2002 at = 01:33:36PM
References:  <sean@chittenden.org> <200204101233.g3ACXaOF052655@hak.lan.Awfulhak.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--bp/iNruPH9dso1Pn
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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

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

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 a value of 2002-4-7 2:0:0.0 becomes 2002-4-7 3:0:0.0 PDT, then
> you can deduce that 2 =3D=3D 3 and go on to deduce other equally bizarre
> things....  Thinking about it makes my head hurt !

Sun Apr 07 02:00:00 PST 2002 =3D 1018173600
Sun Apr 07 03:00:00 PDT 2002 =3D 1018173600

That's a non-issue, I think you head is just going to have to continue
to hurt.  :~) -sc

--=20
Sean Chittenden

--bp/iNruPH9dso1Pn
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Comment: Sean Chittenden <sean@chittenden.org>

iEYEARECAAYFAjy0mGEACgkQn09c7x7d+q1ZGgCg2ZN3pJqLYpYbX9qZu3Ps2bLc
B74AoKd6OoQipiWoarEyS/5yKn9U6oAr
=mJt9
-----END PGP SIGNATURE-----

--bp/iNruPH9dso1Pn--

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020410125409.B34587>