Re: Conversion errors for datetime fields

> 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