Re: Bad timestamp external representation

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Bad timestamp external representation
Date: 2001-07-26 21:38:23
Message-ID: 200107262138.f6QLcNE05631@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

> On Wed, Jul 25, 2001 at 06:53:21PM -0400, Bruce Momjian wrote:
> >
> > I can confirm that current CVS sources have the same bug.
> >
> > > It's a bug in timestamp output.
> > >
> > > # select '2001-07-24 15:55:59.999'::timestamp;
> > > ?column?
> > > ---------------------------
> > > 2001-07-24 15:55:60.00-04
> > > (1 row)
> > >
> > > Richard Huxton wrote:
> > > >
> > > > From: "tamsin" <tg_mail(at)bryncadfan(dot)co(dot)uk>
> > > >
> > > > > Hi,
> > > > >
> > > > > Just created a db from a pg_dump file and got this error:
> > > > >
> > > > > ERROR: copy: line 602, Bad timestamp external representation '2000-10-03
> > > > > 09:01:60.00+00'
> > > > >
> > > > > I guess its a bad representation because 09:01:60.00+00 is actually 09:02,
> > > > > but how could it have got into my database/can I do anything about it?
> > > > The
> > > > > value must have been inserted by my app via JDBC, I can't insert that
> > > > value
> > > > > directly via psql.
> > > >
> > > > Seem to remember a bug in either pg_dump or timestamp rendering causing
> > > > rounding-up problems like this. If no-one else comes up with a definitive
> > > > answer, check the list archives. If you're not running the latest release,
> > > > check the change-log.
>
> 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?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tony Reina 2001-07-26 22:06:03 Re: Replication with PostgreSQL
Previous Message Roderick A. Anderson 2001-07-26 21:14:03 Re: What's going on here?

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-07-26 21:48:13 Re: Revised Patch to allow multiple table locks in "Unison"
Previous Message Bruce Momjian 2001-07-26 21:28:55 Re: Re: Re: Storing XML in PostgreSQL