> > > It is not a bug, in general, to generate or accept times like
> > > 09:01:60. Leap seconds are inserted as the 60th second of a minute.
> > > ANSI C defines the range of struct member tm.tm_sec as "seconds
> > > after the minute [0-61]", inclusive, and strftime format %S as "the
> > > second as a decimal number (00-61)". A footnote mentions "the range
> > > [0-61] for tm_sec allows for as many as two leap seconds".
> > >
> > > This is not to say that pg_dump should misrepresent stored times,
> > > but rather that PG should not reject those misrepresented times as
> > > being ill-formed. We were lucky that PG has the bug which causes it
> > > to reject these times, as it led to the other bug in pg_dump being
> > > noticed.
> >
> > We should access :60 seconds but we should round 59.99 to 1:00, right?
>
> If the xx:59.999 occurred immediately before a leap second, rounding it
> up to (xx+1):00.00 would introduce an error of 1.001 seconds.
Oh, so there is a good reason for showing :60.
> As I understand it, the problem is in trying to round 59.999 to two
> digits. My question is, why is pg_dump representing times with less
> precision than PostgreSQL's internal format? Should pg_dump be lossy?
No idea.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026