From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Li Japin <japinli(at)hotmail(dot)com> |
Cc: | Greg Stark <stark(at)mit(dot)edu>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Duplicate function call on timestamp2tm |
Date: | 2019-12-12 16:24:14 |
Message-ID: | 2516.1576167854@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Li Japin <japinli(at)hotmail(dot)com> writes:
> Thanks for your confirm. Is there anything I can do?
No, I've got it.
In adding the test coverage I spoke of, I thought we should allow
the date_part tests to check all the entries in timestamp[tz]_tbl
not just those around current time, and I found an independent
problem:
timestamp | isoyear | week | isodow | dow | doy
-----------------------------+-----------+------+--------+-----+-----
...
Tue Feb 16 17:32:01 0097 BC | -96 | 7 | 2 | 2 | 47
Sat Feb 16 17:32:01 0097 | 97 | 7 | 6 | 6 | 47
that is, the ISOYEAR case is failing to correct for BC years.
We could imagine fixing this in date2isoyear() but I think it's
safer to leave that function alone and do the corrections
in timestamp[tz]_part. Note for example that formatting.c
already applies a BC correction to the result; and I think the
usage in date2isoyearday() requires sticking to the year-zero-exists
convention, too.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2019-12-12 18:05:06 | shared tempfile was not removed on statement_timeout (unreproducible) |
Previous Message | Amit Khandekar | 2019-12-12 16:20:12 | Re: logical decoding : exceeded maxAllocatedDescs for .spill files |