From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | David Steele <david(at)pgmasters(dot)net>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Petr Fedorov <petr(dot)fedorov(at)phystech(dot)edu>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch |
Date: | 2021-04-22 20:26:53 |
Message-ID: | 1197050.1619123213@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
I wrote:
> So I don't think there's any code change required (unless you are still
> worried about speed). What we do need is documentation fixes:
> * clarify the above bit about local vs UTC midnight
> * document the existence of the julian field for date_part/extract
> * fix this bit in the to_char docs to agree with reality,
> ie s/UTC/local time/:
> <entry>Julian Day (integer days since November 24, 4714 BC at midnight UTC)</entry>
> Perhaps it'd be worth documenting that you can get the standard
> astronomical definition of Julian date by transposing to time zone UTC-12
> before converting. But I think trying to change PG's behavior at this
> point would be a bad idea.
Here's a concrete documentation proposal covering this.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
document-julian-dates-better-1.patch | text/x-diff | 4.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-04-22 20:28:36 | Re: posgres 12 bug (partitioned table) |
Previous Message | Andres Freund | 2021-04-22 19:54:40 | Re: posgres 12 bug (partitioned table) |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-04-22 20:28:36 | Re: posgres 12 bug (partitioned table) |
Previous Message | Jeff Janes | 2021-04-22 20:04:18 | Re: SQL-standard function body |