A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=1619 ====================================================================== Reported By: geoffclare Assigned To: ====================================================================== Project: Issue 8 drafts Issue ID: 1619 Category: Base Definitions and Headers Type: Enhancement Request Severity: Comment Priority: normal Status: New Name: Geoff Clare Organization: The Open Group User Reference: Section: 8.3 Page Number: 161 Line Number: 5616 Final Accepted Text: ====================================================================== Date Submitted: 2022-11-18 12:21 UTC Last Modified: 2022-11-21 09:59 UTC ====================================================================== Summary: Add support for TZ=Area/Location ======================================================================
---------------------------------------------------------------------- (0006073) geoffclare (manager) - 2022-11-21 09:59 https://austingroupbugs.net/view.php?id=1619#c6073 ---------------------------------------------------------------------- Here's some alternative wording that disambiguates the 2nd and 3rd formats the way kre suggests (and swaps them round). I don't have any preference between the original wording in the desired action and this alternative, although I can see that this one might be more future-proof. On page 161 line 5616 section 8.3, change:<blockquote>The value of <i>TZ</i> has one of the two forms (spaces inserted for clarity):<pre>:<i>characters</i></pre>or:<pre><i>std offset dst offset, rule</i></pre>If <i>TZ</i> is of the first format (that is, if the first character is a <colon>), the characters following the <colon> are handled in an implementation-defined manner. The expanded format (for all <i>TZ</i>s whose value does not have a <colon> as the first character) is as follows:</blockquote>to:<blockquote>The application shall ensure that the value of <i>TZ</i> has one of the three forms (spaces inserted for clarity):<pre>:<i>characters</i></pre>or:<pre><i>std offset dst offset, rule</i></pre>or: A format specifying a geographical timezone or a special timezone. If <i>TZ</i> is of the first format (that is, if the first character is a <colon>), the characters following the <colon> are handled in an implementation-defined manner. The expanded form of the second format (without the inserted spaces) is as follows:</blockquote> After page 163 line 5700 section 8.3, add:<blockquote>If <i>TZ</i> is of the third format (that is, if the first character is not a <colon> and the value does not match the syntax for the second format), the value indicates either a geographical timezone or a special timezone from an implementation-defined timezone database. Typically these take the form<pre><i>Area</i>/<i>Location</i></pre>as in the IANA timezone database. Examples of geographical timezones that may be supported include <tt>Africa/Cairo</tt>, <tt>America/Indiana/Indianapolis</tt>, <tt>America/New_York</tt>, <tt>Asia/Tokyo</tt>, and <tt>Europe/London</tt>. The data for each geographical timezone shall include: <ul> <li>Whether Daylight Saving Time (DST) is observed, and if so the rules used to determine when the transitions to and from DST occur.</li> <li>The offset from Coordinated Universal Time of the timezone's standard time and, if observed, of its DST.</li> <li>The timezone names for standard time (<i>std</i>) and, if observed, for DST (<i>dst</i>) to be used by <i>tzset</i>(). These shall each contain no more than {TZNAME_MAX} bytes.</li> </ul> If there are any historical variations, or known future variations, of the above data for a geographical timezone, these variations shall be included in the database, except that historical variations from before the Epoch need not be included. If the database incorporates the geographical timezones from the IANA timezone database, the implementation should provide a way to update it in accordance with RFC 6557; if this recommendation is not followed, an implementation-defined way to update the database shall be provided. Implementations shall support the special timezone <tt>Etc/UTC</tt> and may support additional implementation-defined special timezones. The behavior for <tt>TZ=Etc/UTC</tt> shall be identical to <tt>TZ=UTC0</tt> (as described in the second format above).</blockquote> On page 3460 line 118332 section A.8.3, change:<blockquote>Implementations are encouraged to use the time zone database maintained by IANA to determine when Daylight Saving Time changes occur and to handle <i>TZ</i> values that start with a <colon>. See RFC 6557.</blockquote>to:<blockquote>Implementations are encouraged to incorporate the IANA timezone database into the timezone database used for <i>TZ</i> values of the form <i>Area</i>/<i>Location</i> and to provide a way to update it in accordance with RFC 6557. The <i>TZ</i> format beginning with <colon> was originally introduced as a way for implementations to support geographical timezones in the form :<i>Area</i>/<i>Location</i> as an extension, but implementations started to support them without the leading <colon> (as well as with it) and their use without the <colon> became the de-facto standard. Consequently when geographical timezones were added to this standard, it was without the <colon>.</blockquote> Issue History Date Modified Username Field Change ====================================================================== 2022-11-18 12:21 geoffclare New Issue 2022-11-18 12:21 geoffclare Name => Geoff Clare 2022-11-18 12:21 geoffclare Organization => The Open Group 2022-11-18 12:21 geoffclare Section => 8.3 2022-11-18 12:21 geoffclare Page Number => 161 2022-11-18 12:21 geoffclare Line Number => 5616 2022-11-18 12:23 geoffclare Desired Action Updated 2022-11-18 21:44 steffen Note Added: 0006065 2022-11-19 18:23 kre Note Added: 0006068 2022-11-21 09:59 geoffclare Note Added: 0006073 ======================================================================
