From owner-freebsd-standards Thu Apr 11 3:23:41 2002 Delivered-To: freebsd-standards@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 78C4537B404 for ; Thu, 11 Apr 2002 03:23:37 -0700 (PDT) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [IPv6:fec0::1:12]) by Awfulhak.org (8.12.2/8.11.6) with ESMTP id g3BANXoi040778; Thu, 11 Apr 2002 11:23:33 +0100 (BST) (envelope-from brian@freebsd-services.com) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.12.2/8.12.2) with ESMTP id g3BANUOF032971; Thu, 11 Apr 2002 11:23:30 +0100 (BST) (envelope-from brian@freebsd-services.com) Message-Id: <200204111023.g3BANUOF032971@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Sean Chittenden Cc: Brian Somers , freebsd-standards@FreeBSD.org Subject: Re: mktime() doesn't fix deadzones... In-Reply-To: Message from Sean Chittenden of "Wed, 10 Apr 2002 12:54:09 PDT." <20020410125409.B34587@ninja1.internal> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 11 Apr 2002 11:23:30 +0100 From: Brian Somers 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 > [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 http://www.freebsd-services.com/ Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message