contains files
    <filename>Africa.txt</filename>, <filename>America.txt</filename>, etc., containing
    information about every time zone abbreviation known to be in use
    according to the IANA timezone database.  The zone name
    definitions found in these files can be copied and pasted into a custom
    configuration file as needed.  Note that these files cannot be directly
    referenced as <varname>timezone_abbreviations</varname> settings, because of
    the dot embedded in their names.
   </para>

   <note>
    <para>
     If an error occurs while reading the time zone abbreviation set, no new
     value is applied and the old set is kept. If the error occurs while
     starting the database, startup fails.
    </para>
   </note>

   <caution>
    <para>
     Time zone abbreviations defined in the configuration file override
     non-timezone meanings built into <productname>PostgreSQL</productname>.
     For example, the <filename>Australia</filename> configuration file defines
     <literal>SAT</literal> (for South Australian Standard Time).  When this
     file is active, <literal>SAT</literal> will not be recognized as an abbreviation
     for Saturday.
    </para>
   </caution>

   <caution>
    <para>
     If you modify files in <filename>.../share/timezonesets/</filename>,
     it is up to you to make backups &mdash; a normal database dump
     will not include this directory.
    </para>
   </caution>

  </sect1>

  <sect1 id="datetime-posix-timezone-specs">
  <title><acronym>POSIX</acronym> Time Zone Specifications</title>

  <indexterm zone="datetime-posix-timezone-specs">
   <primary>time zone</primary>
   <secondary><acronym>POSIX</acronym>-style specification</secondary>
  </indexterm>

  <para>
   <productname>PostgreSQL</productname> can accept time zone specifications
   that are written according to the <acronym>POSIX</acronym> standard's rules
   for the <varname>TZ</varname> environment
   variable.  <acronym>POSIX</acronym> time zone specifications are
   inadequate to deal with the complexity of real-world time zone history,
   but there are sometimes reasons to use them.
  </para>

  <para>
   A POSIX time zone specification has the form
<synopsis>
<replaceable>STD</replaceable> <replaceable>offset</replaceable> <optional> <replaceable>DST</replaceable> <optional> <replaceable>dstoffset</replaceable> </optional> <optional> , <replaceable>rule</replaceable> </optional> </optional>
</synopsis>
   (For readability, we show spaces between the fields, but spaces should
   not be used in practice.)  The fields are:
   <itemizedlist>
    <listitem>
     <para>
      <replaceable>STD</replaceable> is the zone abbreviation to be used
      for standard time.
     </para>
    </listitem>
    <listitem>
     <para>
      <replaceable>offset</replaceable> is the zone's standard-time offset
      from UTC.
     </para>
    </listitem>
    <listitem>
     <para>
      <replaceable>DST</replaceable> is the zone abbreviation to be used
      for daylight-savings time.  If this field and the following ones are
      omitted, the zone uses a fixed UTC offset with no daylight-savings
      rule.
     </para>
    </listitem>
    <listitem>
     <para>
      <replaceable>dstoffset</replaceable> is the daylight-savings offset
      from UTC.  This field is typically omitted, since it defaults to one
      hour less than the standard-time <replaceable>offset</replaceable>,
      which is usually the right thing.
     </para>
    </listitem>
    <listitem>
     <para>
      <replaceable>rule</replaceable> defines the rule for when daylight
      savings is in effect, as described below.
     </para>
    </listitem>
   </itemizedlist>
  </para>

  <para>
   In this syntax, a zone abbreviation can be a string of letters, such
   as <literal>EST</literal>, or an arbitrary string surrounded by angle
   brackets, such as <literal>&lt;UTC-05&gt;</literal>.
   Note that the zone abbreviations given here are only used for output,