From owner-freebsd-standards Wed Apr 10 12:54:41 2002 Delivered-To: freebsd-standards@freebsd.org Received: from mail.tgd.net (mail.tgd.net [209.81.25.10]) by hub.freebsd.org (Postfix) with ESMTP id 9288A37B43F; Wed, 10 Apr 2002 12:54:09 -0700 (PDT) Received: by mail.tgd.net (Postfix, from userid 1001) id 6552420F1F; Wed, 10 Apr 2002 12:54:09 -0700 (PDT) Date: Wed, 10 Apr 2002 12:54:09 -0700 From: Sean Chittenden To: Brian Somers Cc: freebsd-standards@FreeBSD.org, current@freebsd.org Subject: Re: mktime() doesn't fix deadzones... Message-ID: <20020410125409.B34587@ninja1.internal> References: <200204101233.g3ACXaOF052655@hak.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200204101233.g3ACXaOF052655@hak.lan.Awfulhak.org>; from "brian@freebsd-services.com" on Wed, Apr 10, 2002 at = 01:33:36PM X-PGP-Key: 0x1EDDFAAD X-PGP-Fingerprint: C665 A17F 9A56 286C 5CFB 1DEA 9F4F 5CEF 1EDD FAAD X-Web-Homepage: http://sean.chittenden.org/ Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --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 iEYEARECAAYFAjy0mGEACgkQn09c7x7d+q1ZGgCg2ZN3pJqLYpYbX9qZu3Ps2bLc B74AoKd6OoQipiWoarEyS/5yKn9U6oAr =mJt9 -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message