From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | rgc(at)rgc1(dot)inka(dot)de |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15127: epoch lies 1 hour ahead |
Date: | 2018-03-22 14:35:02 |
Message-ID: | 32426.1521729302@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
=?utf-8?q?PG_Bug_reporting_form?= <noreply(at)postgresql(dot)org> writes:
> I think there is a bug in 10.2.
> Compared to my old 9.1.18 installation, extracted epoch values lie 1h
> ahead.
Hm. I get
regression=# select extract(epoch from timestamptz '2018-03-22 11:50:00+01');
date_part
------------
1521715800
(1 row)
in either HEAD or 9.1.24 (don't have a build of 9.1.18 laying about),
and this agrees with outside tools such as "date", so I think it's
the right answer. I'm not sure why your 9.1.18 installation is giving
a different answer. At this time of year, though, a discrepancy in
opinions about the DST transition date is the first theory that springs
to mind. I wonder which version of the tzdata database your 9.1.18
is using.
I also find this in the 9.1.23 release notes:
<listitem>
<para>
Update our copy of the timezone code to match
IANA's <application>tzcode</application> release 2016c (Tom Lane)
</para>
<para>
This is needed to cope with anticipated future changes in the time
zone data files. It also fixes some corner-case bugs in coping with
unusual time zones.
</para>
</listitem>
so it's not out of the question that the behavior discrepancy arises
from a since-fixed bug.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2018-03-22 15:02:21 | Re: BUG #15128: Erroneous inner query is executing with wrong results |
Previous Message | PG Bug reporting form | 2018-03-22 14:25:01 | BUG #15128: Erroneous inner query is executing with wrong results |