Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0001816 [Issue 8 drafts] System Interfaces Objection Error 2024-02-23 08:54 2024-04-29 15:48
Reporter eggert View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Resolved   Product Version Draft 4.1
Name Paul Eggert
Organization UCLA Computer Science
User Reference
Section daylight, timezone, tzname
Page Number 2310-2311
Line Number 75175-75207
Final Accepted Text See Note: 0006774.
Summary 0001816: daylight, timezone, tzname do not work with location-based TZ
Description Although the external variables daylight, timezone, and tzname have well-defined values for POSIX.1-2017 TZ settings, they do not work with location-based TZ settings. For example, with TZ="Europe/Moscow", since 1970 there have been four distinct abbreviations "EET", "EEST", "MSK" and "MSD", and MSK has sometimes stood for +0300 and sometimes for +0400.

In practice, I think implementations that support location-based TZ settings set these external variables haphazardly, since the TZif representation doesn't correspond to POSIX.1-2017. User code should therefore not rely on these variables' values when location-based settings are used.

The proposed action attempts to change the standard to describe this situation. It continues to require traditional POSIX behavior for traditional TZ settings (which it calls "stdoffsettish timezones" for lack of a better term). It also gives FUTURE DIRECTIONS in which these external variables will be removed. It does not propose marking the variables as obsolescent because, as I understand it, it's too late to do that in this go-round of the standard.
Desired Action 8.3 Other Environment Variables, TZ, page 176 line 6219

Prepend the following text to line 6219, and put "stdoffsettish timezone" into the index.

  A stdoffsettish timezone" is one that is defined by a TZ of the second format.


<time.h> FUTURE DIRECTIONS page 454 line 15856

Change "None" to "The variables daylight, timezone, and tzname are planned to be removed, as they have unspecified values unless the timezone is stdoffsettish."


daylight page 801 lines 27442-27448 (the entire page)

Remove this page, since 'daylight' is already documented under tzset(), and there's no reason to give it a separate page (there is no page for the related variable tzname).

Alternately, add a FUTURE DIRECTIONS section saying "This variable is planned to be removed, as it has an unspecified value unless the timezone is stdoffsettish."

Similarly for timezone, page 2279 lines 74379-74385 (the entire page).


strptime APPLICATION USAGE page 2160

line 70602: Change "If this name matches" to "If the local timezone is stdoffsettish and this name matches".

line 70604: Likewise.


tzset DESCRIPTION page 2310

line 75175: Prepend "If the local timezone is stdoffsetish,"

line 75179: Also prepend "If the local timezone is stdoffsetish,"

Line 75182: Append the following paragraph:

  If the local timezone is not stdoffsettish, the tzset() function may set the external variables tzname, daylight and timezone to unspecified values.

line 75199 (APPLICATION USAGE) Append the following paragraph:

  The values of the variables daylight, timezone, and tzname should be used only if the local timezone is known to be stdoffsettish.

page 2311 line 75207 (FUTURE DIRECTIONS): Change "None" to "The variables daylight, timezone, and tzname are planned to be removed, as they have unspecified values unless the local timezone is stdoffsettish."
Tags tc1-2024
Attached Files

- Relationships
related to 0001797Interpretation Required 1003.1(2024)/Issue8 strftime "%s" should be able to examine tm_gmtoff 

-  Notes
(0006678)
kre (reporter)
2024-02-25 07:07

 I entirely agree with this change, except that as I understand things,
it is already too late for any changes in this area in "the current go-
round" of the standard.

The best that can happen is for the FUTURE DIRECTIONS to get added to
Issue 8 TC1 when that appears in a few years (I'm guessing) and for
the actual changes (to remove that obsolete nonsense - and given that
Issue 8 will require tm_zone and tm_gmtoff, I'd simply remove them for
all usages in Issue 9, they're no longer needed for anything, and
horribly inadequate in many cases).

But please, don't create something called "stdoffsetish" - that's horrible.
If there is a need for names for the different ways of specifying TZ,
give them better names (but if the 3 vars are simply dropped, the need,
for the purposes here anyway, would no longer exist.)
(0006687)
eggert (reporter)
2024-02-26 18:06

 Here is a revised desired action that reflects kre's comments. It separates the FUTURE DIRECTIONS changes into a later part marked "Changes for Issue 8 TC1", and it replaces "stdoffsettish timezone" with "timezone that corresponds to a TZ of the second format" since nobody thought of better names.

I didn't know that a future version of POSIX could simply remove the affected variables, without marking them as obsolescent in an intervening version.


---- Changes that can be done as an interpretation now ----

daylight page 801 lines 27442-27448 (the entire page)

(This part of the change is editorial, to make the other changes simpler.)

Remove this page, since 'daylight' is already documented under tzset(), and there's no reason to give it a separate page (there is no page for the related variable tzname).

Similarly for timezone, page 2279 lines 74379-74385 (the entire page, which oddly is labeled "timezone()" at top right).


strptime APPLICATION USAGE page 2160

line 70602: Change "If this name matches" to "If the local timezone corresponds to a TZ of the second format and this name matches".

line 70604: Likewise.


tzset DESCRIPTION page 2310

line 75175: Prepend "If the local timezone corresponds to a TZ of the second format,"

line 75179: Also prepend "If the local timezone corresponds to a TZ of the second format,"

Line 75182: Append the following paragraph:

  If the local timezone does not correspond to a TZ of the second format, the tzset() function may set the external variables tzname, daylight and timezone to unspecified values.

line 75199 (APPLICATION USAGE) Append the following paragraph:

  The values of the variables daylight, timezone, and tzname should be used only if the local timezone is known to correspond to a TZ of the second format.


The abovementioned newly-added instances of the phrase "TZ of the second format" may need a cross-reference to section 8.3, Other Environment Variables, TZ, page 176 line 6219, to help the reader understand what "TZ of the second format" means.



---- Changes for Issue 8 TC1 ----

<time.h> FUTURE DIRECTIONS page 454 line 15856

Change "None" to "The variables daylight, timezone, and tzname are planned to be removed, as they have unspecified values unless the timezone corresponds to a TZ of the second format."

page 2311 line 75207 (FUTURE DIRECTIONS): Change "None" to "The variables daylight, timezone, and tzname are planned to be removed, as they have unspecified values unless the local timezone corresponds to a TZ of the second format."
(0006774)
Don Cragun (manager)
2024-04-29 15:42
edited on: 2024-04-29 17:15

 <time.h> DESCRIPTION page 454 line 15841, change XSI to OB XSI.

line 15843, change CX to OB CX.

<time.h> FUTURE DIRECTIONS page 454 line 15856, change "None" to:
The variables daylight, timezone, and tzname are planned to be removed in a future version of this standard, as they have unspecified values unless the environment variable TZ is of the second format.

daylight SYNOPSIS page 801 line 27445, change XSI to OB XSI.

strptime DESCRIPTION page 2160 lines 70602-70606: add OB shading to "If this name matches ... shall be set to 0."

timezone SYNOPSIS page 2279 line 74382, change XSI to OB XSI.
Also remove the "()" after timezone in the page heading.

tzset SYNOPSIS page 2310

line 75167: change XSI to OB XSI
line 75169: change CX to OB CX
line 75170: add CX margin marker

tzset DESCRIPTION page 2310

lines 75175-75178 add OB margin marker and shading

line 75175: Prepend "If the value of TZ is of the second format,"

line 75178: change "as described in XBD Chapter 8 (on page 167)" to "as described for the second TZ format in XBD Section 8.3 (on page 174)"

line 75179: change XSI to OB XSI

line 75179: Also prepend "If the value of TZ is of the second format,"

Line 75182: Append the following paragraph:
[OB]If the value of TZ is not of the second format, the tzset() function shall set the array elements of the external variable tzname to point to unspecified string values[/OB]

[OB XSI]and shall set the external variables daylight and timezone to unspecified values.[/OB XSI]

line 75183: change XSI to OB XSI

line 75199 (APPLICATION USAGE) Append the following paragraph:
The values of the variables daylight, timezone, and tzname can only be relied upon to reflect the local timezone information if the environment variable TZ value is of the second format. Applications should use the tm_zone member of the tm structure instead of tzname and the tm_gmtoff member instead of timezone. When using tm_zone and tm_gmtoff there is no need for the information that is available in daylight.

page 2311 line 75207 (tzset() FUTURE DIRECTIONS), change "None" to:
The variables daylight, timezone, and tzname are planned to be removed in a future version of this standard, as they have unspecified values unless the environment variable TZ is of the second format.

page 2311 line 75210 (tzset() SEE ALSO), change:
XBD Chapter 8 (on page 167)
to:
XBD Section 8.3 (on page 174)

- Issue History
Date Modified Username Field Change
2024-02-23 08:54 eggert New Issue
2024-02-23 08:54 eggert Name => Paul Eggert
2024-02-23 08:54 eggert Organization => UCLA Computer Science
2024-02-23 08:54 eggert Section => daylight, timezone, tzname
2024-02-23 08:54 eggert Page Number => 2310-2311
2024-02-23 08:54 eggert Line Number => 75175-75207
2024-02-25 07:07 kre Note Added: 0006678
2024-02-26 18:06 eggert Note Added: 0006687
2024-02-26 19:23 eblake Relationship added related to 0001797
2024-04-29 15:42 Don Cragun Note Added: 0006774
2024-04-29 15:46 Don Cragun Note Edited: 0006774
2024-04-29 15:47 Don Cragun Note Edited: 0006774
2024-04-29 15:48 Don Cragun Final Accepted Text => See Note: 0006774.
2024-04-29 15:48 Don Cragun Status New => Resolved
2024-04-29 15:48 Don Cragun Resolution Open => Accepted As Marked
2024-04-29 15:50 Don Cragun Tag Attached: tc1-2024
2024-04-29 17:15 Don Cragun Note Edited: 0006774

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker