Steve Rogerson 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
2023年4月6日(木) 0:02 Steve Rogerson :
>
> 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
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.
Erik Wienhold writes:
>> On 05/04/2023 11:18 CEST Steve Rogerson
>> 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.
> On 05/04/2023 11:18 CEST Steve Rogerson
> 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
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
