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.
