[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/pgp00000.pgp
Description: PGP signature
