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
