Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch

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: Whole Thread | Raw Message | 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

In response to

Responses

Browse pgsql-bugs by date

  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)

Browse pgsql-hackers by date

  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