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

Reply via email to