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-02-26 19:23
Reporter eggert View Status public  
Assigned To
Priority normal Resolution Open  
Status New   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
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 No tags attached.
Attached Files

- Relationships
related to 0001797New 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."

- 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

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