Обсуждение: Possible old and fixed bug in Postgres?
I was looking at perl CPAN Module (DateTime::Format::Pg) and saw that it did something that seemed odd to me with time zones, based on the comment: # For very early and late dates, PostgreSQL always returns times in # UTC and does not tell us that it did so. Early is before 1901-12-14 and late after 2038-01-18 A quick test setting my time zone to be America/Chicago I got select '1900-01-01 00:00:00'::timestamptz; timestamptz ------------------------ 1900-01-01 00:00:00-06 (1 row) and select '2040-01-01 00:00:00'::timestamptz; timestamptz ------------------------ 2040-01-01 00:00:00-06 These seemed correct to me. I'm guessing this might have been a bug/feature of pg in the long ago. Steve
> On 05/04/2023 11:18 CEST Steve Rogerson <steve.git@woodsideendurance.co.uk> wrote: > > I was looking at perl CPAN Module (DateTime::Format::Pg) and saw that it did > something that seemed odd to me with time zones, based on the comment: > > # For very early and late dates, PostgreSQL always returns times in > # UTC and does not tell us that it did so. > > Early is before 1901-12-14 and late after 2038-01-18 > > A quick test setting my time zone to be America/Chicago I got > > select '1900-01-01 00:00:00'::timestamptz; > timestamptz > ------------------------ > 1900-01-01 00:00:00-06 > (1 row) > > and > > select '2040-01-01 00:00:00'::timestamptz; > timestamptz > ------------------------ > 2040-01-01 00:00:00-06 > > > These seemed correct to me. I'm guessing this might have been a bug/feature of > pg in the long ago. Judging by the commit message and changed test cases, probably: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=921d749bd4c34c3349f1c254d5faa2f1cec03911 -- Erik
Erik Wienhold <ewie@ewie.name> writes: >> On 05/04/2023 11:18 CEST Steve Rogerson <steve.git@woodsideendurance.co.uk> wrote: >> # For very early and late dates, PostgreSQL always returns times in >> # UTC and does not tell us that it did so. >> Early is before 1901-12-14 and late after 2038-01-18 >> ... >> These seemed correct to me. I'm guessing this might have been a bug/feature of >> pg in the long ago. > Judging by the commit message and changed test cases, probably: > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=921d749bd4c34c3349f1c254d5faa2f1cec03911 I think this was not fixed in full until 2008: https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=0171e72d4da2da7974ff13c63130e2175cebee88 Either way, though, whatever Steve is looking at is far past its sell-by date. regards, tom lane
On 05/04/2023 11:23, Erik Wienhold wrote: > Judging by the commit message and changed test cases, probably: > > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=921d749bd4c34c3349f1c254d5faa2f1cec03911 > That's the one. I can't see which pg version(s) this turned up in.
2023年4月6日(木) 0:02 Steve Rogerson <steve.git@woodsideendurance.co.uk>: > > On 05/04/2023 11:23, Erik Wienhold wrote: > > Judging by the commit message and changed test cases, probably: > > > > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=921d749bd4c34c3349f1c254d5faa2f1cec03911 > > > That's the one. I can't see which pg version(s) this turned up in. $ git tag --contains 921d749bd4c34c3349f1c254d5faa2f1cec03911 | head -1 REL8_0_0 Regards Ian Barwick
Steve Rogerson <steve.git@woodsideendurance.co.uk> writes:
> That's the one. I can't see which pg version(s) this turned up in.
The pg_time_t change was in 8.0, the later one to support 64-bit tzdata
was in 8.4.
regards, tom lane