From: | Rod Taylor <pg(at)rbt(dot)ca> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Time bug with small years |
Date: | 2011-11-24 04:45:02 |
Message-ID: | CAKddOFAEzv2J1PmVjgEJS5hoJ=zwoqtj26AjfwOL0oUJn3Vfag@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I have no idea what is going on with the minutes/seconds, particularly for
years under 1895 where it gets appended onto the timezone component?
sk_test=# select version();
version
----------------------------------------------------------------------------------------------------------------
PostgreSQL 9.1.1 on x86_64-pc-linux-gnu, compiled by gcc-4.6.real
(Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1, 64-bit
(1 row)
-- uname -a output: Linux rbt-dell 3.0.0-13-generic #22-Ubuntu SMP Wed Nov
2 13:27:26 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
sk_test=# select '1894-01-01'::timestamp with time zone;
timestamptz
------------------------------
1894-01-01 00:00:00-05:17:32
(1 row)
sk_test=# select '1895-01-01'::timestamp with time zone;
timestamptz
------------------------
1895-01-01 00:17:32-05
(1 row)
sk_test=# select '1896-01-01'::timestamp with time zone;
timestamptz
------------------------
1896-01-01 00:00:00-05
(1 row)
sk_test=# show timezone;
TimeZone
-----------
localtime
(1 row)
sk_test=# set timezone= 'est5edt';
SET
sk_test=# select '1895-01-01'::timestamp with time zone;
timestamptz
------------------------
1895-01-01 00:00:00-05
(1 row)
sk_test=# select '1894-01-01'::timestamp with time zone;
timestamptz
------------------------
1894-01-01 00:00:00-05
(1 row)
I can duplicate with the exact same version of Pg on Intel hardware with
kernel:
Linux infongd2888
2.6.28.8-20101130b-iscsi-ntacker-fasync-mremap-amd-sec6-grsec #1 SMP Tue
Nov 30 18:27:29 CET 2010 i686 GNU/Linux
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2011-11-24 04:45:24 | Re: logging in high performance systems. |
Previous Message | David E. Wheeler | 2011-11-24 04:07:18 | Re: Obstacles to user-defined range canonicalization functions |