[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

> 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

Attachment: msg37144/pgp00000.pgp
Description: PGP signature

Reply via email to