On Sun Dec 29, 2024 at 12:47 AM CET, Bruce Momjian wrote:
On Mon, Dec 16, 2024 at 02:57:59PM -0500, Tom Lane wrote: Yes, your patch seems like a big improvement.
+1
+ Before consulting the <varname>timezone_abbreviations</varname> file, + <productname>PostgreSQL</productname> checks to see whether an + abbreviation used in datetime input is defined in the IANA time zone + database entry currently selected by the + <xref linkend="guc-timezone"/> run-time parameter. If so the time + zone's meaning is used, for consistency with datetime output. The + <varname>timezone_abbreviations</varname> file is mainly useful for + allowing datetime input to recognize abbreviations for time zones + other than the active zone. I think it would be good to add some additional clarify here. It was fairly confusing to me. Especially the last sentence, due to the use of "active zone", even though it's really talking about the currently active abbreviations list. Probably my confusion mostly came from the fact that I wasn't aware that timezone abbreviations were localized, but I doubt I'm alone in not knowing this. Maybe something like this (feel free to improve further): Before consulting the <varname>timezone_abbreviations</varname> file, <productname>PostgreSQL</productname> checks to see whether an abbreviation used in datetime input is defined in the currently active IANA time zone database. The abbreviations for these entries are localized based on the <xref linkend="guc-timezone"/> run-time parameter, so depending on the configured <xref linkend="guc-timezone"/> abbreviations will differ. If it is found the IANA time zone database, then that meaning is used for consistency with datetime output. The <varname>timezone_abbreviations</varname> file is only useful for allowing datetime input to recognize abbreviations for time zones that are not defined in the currently active IANA time zone database.
