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 по дате отправления: