364, or to 365 in leap years.
      </para>
     </listitem>
    </varlistentry>
    <varlistentry>
     <term><literal>J</literal><replaceable>n</replaceable></term>
     <listitem>
      <para>
       In this form, <replaceable>n</replaceable> counts from 1 to 365,
       and February 29 is not counted even if it is present.  (Thus, a
       transition occurring on February 29 could not be specified this
       way.  However, days after February have the same numbers whether
       it's a leap year or not, so that this form is usually more useful
       than the plain-integer form for transitions on fixed dates.)
      </para>
     </listitem>
    </varlistentry>
    <varlistentry>
     <term><literal>M</literal><replaceable>m</replaceable><literal>.</literal><replaceable>n</replaceable><literal>.</literal><replaceable>d</replaceable></term>
     <listitem>
      <para>
       This form specifies a transition that always happens during the same
       month and on the same day of the week.  <replaceable>m</replaceable>
       identifies the month, from 1 to 12.  <replaceable>n</replaceable>
       specifies the <replaceable>n</replaceable>'th occurrence of the
       weekday identified by <replaceable>d</replaceable>.
       <replaceable>n</replaceable> is a number between 1 and 4, or 5
       meaning the last occurrence of that weekday in the month (which
       could be the fourth or the fifth).  <replaceable>d</replaceable> is
       a number between 0 and 6, with 0 indicating Sunday.
       For example, <literal>M3.2.0</literal> means <quote>the second
       Sunday in March</quote>.
      </para>
     </listitem>
    </varlistentry>
   </variablelist>
  </para>

  <note>
   <para>
    The <literal>M</literal> format is sufficient to describe many common
    daylight-savings transition laws.  But note that none of these variants
    can deal with daylight-savings law changes, so in practice the
    historical data stored for named time zones (in the IANA time zone
    database) is necessary to interpret past time stamps correctly.
   </para>
  </note>

  <para>
   The time fields in a transition rule have the same format as the offset
   fields described previously, except that they cannot contain signs.
   They define the current local time at which the change to the other
   time occurs.  If omitted, they default to <literal>02:00:00</literal>.
  </para>

  <para>
   If a daylight-savings abbreviation is given but the
   transition <replaceable>rule</replaceable> field is omitted,
   the fallback behavior is to use the
   rule <literal>M3.2.0,M11.1.0</literal>, which corresponds to USA
   practice as of 2020 (that is, spring forward on the second Sunday of
   March, fall back on the first Sunday of November, both transitions
   occurring at 2AM prevailing time).  Note that this rule does not
   give correct USA transition dates for years before 2007.
  </para>

  <para>
   As an example, <literal>CET-1CEST,M3.5.0,M10.5.0/3</literal> describes
   the current (as of 2020) timekeeping practice in Paris.  This specification
   says that standard time has the abbreviation <literal>CET</literal> and
   is one hour ahead (east) of UTC; daylight savings time has the
   abbreviation <literal>CEST</literal> and is implicitly two hours ahead
   of UTC; daylight savings time begins on the last Sunday in March at 2AM
   CET and ends on the last Sunday in October at 3AM CEST.
  </para>

  <para>
   The four timezone names <literal>EST5EDT</literal>,
   <literal>CST6CDT</literal>, <literal>MST7MDT</literal>,
   and <literal>PST8PDT</literal> look like they are POSIX zone
   specifications.  However, they actually are treated as named time zones
   because (for historical reasons) there are files by those names in the
   IANA time zone database.  The practical implication of this is that
   these zone names will produce valid historical USA daylight-savings
   transitions, even when a plain POSIX specification would not.
  </para>