mktime() doesn't fix deadzones...
I haven't read POSIX yet, but mktime() fails on the boundary condition blackholes when timezones change. I just filed a patch for the PostgreSQL port so that it deals with this problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=36954 I believe that Linux and SunOS handle this automatically and am wondering if FreeBSD should too (this was the 1st time the PostgreSQL guys had heard of this in over 6 years). I'm not a daylight savings expert, but am wondering what other people think. Seems like a good idea(TM) to me. For example (PST/PDT assumed): 2002-4-7 2:0:0.0 should be: 2002-4-7 3:0:0.0 Anyone object or have any thoughts? -sc -- Sean Chittenden msg37133/pgp0.pgp Description: PGP signature
Re: mktime() doesn't fix deadzones...
Hi, I've cc'd -standards as I think this would be of interest there. IMHO the SQL code you quote in the PR should fail with an ``invalid time'' error. 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. The really big question is, how can you ``fix'' mktime() ? 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 == 3 and go on to deduce other equally bizarre things Thinking about it makes my head hurt ! I haven't read POSIX yet, but mktime() fails on the boundary condition blackholes when timezones change. I just filed a patch for the PostgreSQL port so that it deals with this problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=3D36954 I believe that Linux and SunOS handle this automatically and am wondering if FreeBSD should too (this was the 1st time the PostgreSQL guys had heard of this in over 6 years). I'm not a daylight savings expert, but am wondering what other people think. Seems like a good idea(TM) to me. For example (PST/PDT assumed): 2002-4-7 2:0:0.0 should be: 2002-4-7 3:0:0.0 Anyone object or have any thoughts? -sc -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] 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 [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mktime() doesn't fix deadzones...
[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 += 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 == 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 = 1018173600 Sun Apr 07 03:00:00 PDT 2002 = 1018173600 That's a non-issue, I think you head is just going to have to continue to hurt. :~) -sc -- Sean Chittenden msg37144/pgp0.pgp Description: PGP signature
