Re: Issues with EPOCH-s, TIMESTAMP(TZ)-s and leap seconds. - Mailing list pgsql-general

From Tom Lane
Subject Re: Issues with EPOCH-s, TIMESTAMP(TZ)-s and leap seconds.
Date
Msg-id 739281.1738016587@sss.pgh.pa.us
Whole thread Raw
In response to Issues with EPOCH-s, TIMESTAMP(TZ)-s and leap seconds.  (Nem Tudom <ellenallhatatlan@gmail.com>)
List pgsql-general
"Peter J. Holzer" <hjp-pgsql@hjp.at> writes:
> On 2025-01-27 21:01:59 +0000, Nem Tudom wrote:
>> I thought that the EPOCH was the number of seconds since 1970-01-01
>> 00:00:00? Is this incorrect?

> The POSIX standard mandates that leap seconds must be ignored. It's not
> really "number of seconds since 1970-01-01", but "number of days since
> 1970-01-01 times 86400 plus number of seconds in the current day".

I'm not sure what POSIX says about this, but that is the definition
Postgres uses --- and we won't let you select a timezone setting
that does account for leap seconds.

postgres=# set timezone = 'America/New_York';
SET
postgres=# set timezone = 'right/America/New_York';
ERROR:  time zone "right/America/New_York" appears to use leap seconds
DETAIL:  PostgreSQL does not support leap seconds.

If we did support that, it'd enormously complicate all timestamp
arithmetic --- and we could hardly do calculations with times in
the future at all, given the uncertainty around when leap seconds
will be declared.  So if you want to do astronomical timekeeping,
you should use some other data type than timestamptz.

            regards, tom lane



pgsql-general by date:

Previous
From: Shaheed Haque
Date:
Subject: Re: Content of pg_publication using a local connection versus network connection?
Next
From: Thomas Munro
Date:
Subject: Re: Issues with EPOCH-s, TIMESTAMP(TZ)-s and leap seconds.