Re: BUG #15127: epoch lies 1 hour ahead

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #15127: epoch lies 1 hour ahead
Дата
Msg-id 32426.1521729302@sss.pgh.pa.us
обсуждение исходный текст
Ответ на BUG #15127: epoch lies 1 hour ahead  (PG Bug reporting form <noreply@postgresql.org>)
Список pgsql-bugs
=?utf-8?q?PG_Bug_reporting_form?= <noreply@postgresql.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


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

Предыдущее
От: PG Bug reporting form
Дата:
Сообщение: BUG #15128: Erroneous inner query is executing with wrong results
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: BUG #15128: Erroneous inner query is executing with wrong results