Re: BUG #1927: incorrect timestamp returned

Поиск
Список
Период
Сортировка
От Jim C. Nasby
Тема Re: BUG #1927: incorrect timestamp returned
Дата
Msg-id 20051004164252.GM40138@pervasive.com
обсуждение исходный текст
Ответ на Re: BUG #1927: incorrect timestamp returned  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список pgsql-bugs
On Tue, Oct 04, 2005 at 11:20:15AM -0400, Alvaro Herrera wrote:
> On Tue, Oct 04, 2005 at 10:40:11AM -0400, Bruce Momjian wrote:
> > Kouber Saparev wrote:
> > > >>
> > > >>select timestamp '2005-09-23 23:59:59.9999999'
> > > >>
> > > >>I get the following result (note the value of the seconds):
> > > >>
> > > >>2005-09-23 23:59:60.00
> > > >
> > > > It's the leap second.
> > >
> > > It is not a leap second. Leap seconds are always either on the 30th of
> > > June or on the 31th of December.
> > >
> > > Here there is a list of all the leap seconds so far:
> > > http://en.wikipedia.org/wiki/Leap_second
> > >
> > > And, in fact, the wrong result is the same for each date, regardless of
> > > the year, month or day.
> >
> > Right.  We allow leap seconds for any date/time.  Are you saying we
> > should only allow them for certain dates/times?
>
> We should do that for timestamp or timestamptz, but there's no way we
> could check for a bare time or timetz ...
>
> Also it'd require a recompile whenever a new leap second is added; and
> that the Wikipedia hints that leap seconds may disappear in 2008 in
> favor of "leap hours", whatever that may be.

Well, if they only add leap seconds on pre-defined days then we could
only allow them on those days. To wit:

"Leap seconds occur only at the end of a UTC month, and have only ever
been inserted at the end of June 30 or December 31. Unlike leap days,
they occur simultaneously worldwide; for example, a leap second on 31
December will be observed as 6:59:60 pm U.S. Eastern Standard Time."

So that means that the only time a leap second should be allowed is June
30 23:59:60 *UTC* or Dec. 31 23:59:60 *UTC*.

Given the recent discussion about time rounding issues, etc, it might
actually make sense to do this.

Something else to note:

"The announcement to insert a leap second is usually issued whenever the
difference between UTC and UT1 approaches 0.7s, to keep the difference
between UTC and UT1 from exceeding ±0.9 s. After UTC 23:59:59, a
positive leap second at 23:59:60 would be counted, before the clock
indicates 00:00:00 of the next day. Negative leap seconds are also
possible should the Earth's rotation become slightly faster; in that
case, 23:59:58 would be followed by 00:00:00."

Obviously, trying to comply with that to the letter would be a heck of a
lot harder. Unfortunately, if we ever do have a negative leap second I
suspect it could confuse a whole lot of applications...

I wonder if there are any users who actaully care about these
differences. I suspect astronomers have some other time system they
use... can't think of anyone else who might care.
--
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

В списке pgsql-bugs по дате отправления:

Предыдущее
От: "Jean-Pierre Pelletier"
Дата:
Сообщение: Possibly corrupted shared memory, PostgreSQL 8.1 beta2, Windows 2000
Следующее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: BUG #1937: Parts of information_schema only accessible to owner