From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Larry Rosenman <ler(at)lerctr(dot)org> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Conversion errors for datetime fields |
Date: | 2000-12-29 04:00:14 |
Message-ID: | 9592.978062414@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
> Oh, and the UnixWare strftime man page allows %s to return 00-61.
They're just repeating a common mistake. If you want to learn something
about the subject, try some non-computer timekeeping references, for
example the US Naval Observatory:
http://tycho.usno.navy.mil/leapsec.html
After digging around a little, the source of this particular meme
seems to be the old C standard. The theory among those who are
aware it's an error is that some member of the ISO C committee did
enough research to know that two leap seconds could be inserted
in a single year, but not enough to realize that they wouldn't be
inserted in the same minute. (See above USNO page: in fact there
are four agreed-on windows for leap second insertion per year,
but only two have been used historically.) The error has since
contaminated the Java spec, as well as most all Unix documentation.
I suspect that this error may go back even further, perhaps to the
original Unix C library documentation. In any case it was only a
documentation error, as no C library of that vintage actually had
any leap-second support whatever.
> SO, we need to allow it as well. I suspect the C99 standard or
> some other POSIX/SUS/etc standard changed.
C99 *corrects* this error; it specifies 0-60 not 0-61 as the range
of tm_sec. (It also describes actual support for leap-second
timekeeping, which the original C standard did not.)
But this is all irrelevant, anyway, unless you want people to install
atomic clocks before they can run Postgres. We don't have support for
leap-second timekeeping, and few if any of the platforms we run on
do either. IMHO, accepting :60 when we do not have the ability to do
anything correct with it won't improve matters.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Larry Rosenman | 2000-12-29 04:13:56 | Re: Conversion errors for datetime fields |
Previous Message | Tom Lane | 2000-12-29 02:44:06 | Re: Conversion errors for datetime fields |