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
0001252 [1003.1(2016/18)/Issue7+TC2] Base Definitions and Headers Objection Enhancement Request 2019-06-02 21:37 2024-06-11 09:08
Reporter eggert View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Paul Eggert
Organization UCLA
User Reference
Section 8.3 Other Environment Variables - TZ
Page Number 180
Line Number 5945-5946
Interp Status ---
Final Accepted Text Note: 0004458
Summary 0001252: Extend TZ to allow times outside 00-24 range, permanent DST
Description The tzdb project is a widely-used extension to POSIX, and represents the history of a time zone partly via a final POSIX TZ string representing future timestamps. For example, on my Ubuntu system, the TZif file /usr/share/zoneinfo/America/Los_Angeles ends in the line 'PST8PDT,M3.2.0,M11.1.0', which means that one can use TZ='PST8PDT,M3.2.0,M11.1.0' to predict future timestamps. The tzdb project is widely supported and the format of its TZif files has recently been standardized by Internet RFC 8536 <https://tools.ietf.org/html/rfc8536>. [^]

While coauthoring RFC 8536 I noticed that tzdb's use of TZ strings relies on two minor extensions to POSIX's specification of TZ. These extensions were already supported by at least the reference tzcode implementation and by NetBSD, and so are good candidates for standardization by POSIX. Adding them to POSIX will bless the commonly used practice of taking the last line of a TZif file and using it as a TZ string on small platforms that lack room to store the TZif files.

The two minor extensions are specified in Internet RFC 8536 section 3.3.1 "TZ String Extensions" <https://tools.ietf.org/html/rfc8536#page-13>, [^] and the proposed action is to add these to POSIX.

This proposal would address Austin Group issue 0000661 "grammar of TZ variable is insufficient for describing Israel Daylight-saving time", as TZ='IST-2IDT,M3.4.4/26,M10.5.0' represents current rules for Israel, with the '/26' exercising the proposed extension. It would also let POSIX TZ strings represent the current daylight-saving scheme for Godthab, via TZ='<-03>3<-02>,M3.5.0/-2,M10.5.0/-1' where the '/-2' and '/-1' exercise the proposed extension.
Desired Action In the description of the TZ rule, change from:

The /time/ has the same format as /offset/ except that no leading sign ('-' or '+') is allowed.

to:

The /time/ has the same format as /offset/ except that the hour can range from zero to 167. If preceded by a '-', the /time/ shall count backwards before midnight. For example, '47:30' stands for 23:30 the next day, and '-3:30' stands for 20:30 the previous day.


At the end of the description of the TZ rule, add:

Alternative time is in effect all year if it starts January 1 at 00:00 and ends December 31 at 24:00 plus the difference between daylight saving and standard time, leaving no room for standard time in the calendar. For example, TZ='EST5EDT,0/0,J365/25' represents a time zone that observes alternative time all year, being 4 hours west of UTC with abbreviation "EDT".
Tags issue8
Attached Files

- Relationships
related to 0001253Closed 1003.1(2016/18)/Issue7+TC2 clarify that "alternative time" means tm_isdst is positive 
has duplicate 0000661Closedajosey 1003.1(2008)/Issue 7 gramar of TZ variable is insufficient for describing Israel Daylight-saving time 

-  Notes
(0004458)
geoffclare (manager)
2019-06-28 14:28

 Assuming bug 0001253 is accepted, the changes should be ...

On page 280 line 5945 section 8.3, change:
The time has the same format as offset except that no leading sign ('-' or '+') is allowed.
to:
The time has the same format as offset except that the hour can range from zero to 167. If preceded by a '-', the time shall count backwards before midnight. For example, "47:30" stands for 23:30 the next day, and "-3:30" stands for 20:30 the previous day.
Daylight Saving Time is in effect all year if it starts January 1 at 00:00 and ends December 31 at 24:00 plus the difference between Daylight Saving Time and standard time, leaving no room for standard time in the calendar. For example, TZ='EST5EDT,0/0,J365/25' represents a time zone that observes Daylight Saving Time all year, being 4 hours west of UTC with abbreviation "EDT".
(0004459)
shware_systems (reporter)
2019-06-28 17:10

 If the format is to be extended I would also like to see an additional field that encodes latitudes in HMS format, to seconds precision, so the values are not dependant on being associated with a particular political entity name subject to change, and would differentiate that for a given longitude a country at one latitude may use DST, while another may not, and a third may have DST start and end on different days from the first. There is also that time zone lines can zigzag, so at one latitude it may be GMT-7 and another GMT-6 for the same UTC value. For some time zones an additional longitude field establishing the center of the region using this STD/DST may be desirable also, for cities like Sydney that do DST different from other cities in that nominal hour of timezone.

This is more a future direction for the tzdb project to work out, in terms of how much geocoding is actually necessary to fully map current and historic political names, and how to track future changes, but the latitude field is a minimum and I think POSIX could add this as an optional field now.

For localtime() one can think of a time zone as a 15 degree wide slice of the globe, as a simplifying presumption, but this is not the standard reflecting reality of how time zones are actually defined. Their interpretation is location dependant and a location on a globe has both longitude and latitude, not longitude alone.

- Issue History
Date Modified Username Field Change
2019-06-02 21:37 eggert New Issue
2019-06-02 21:37 eggert Name => Paul Eggert
2019-06-02 21:37 eggert Organization => UCLA
2019-06-02 21:37 eggert Section => 8.3 Other Environment Variables - TZ
2019-06-02 21:37 eggert Page Number => unknown; don't have PDF
2019-06-02 21:37 eggert Line Number => unknown; don't have PDF
2019-06-02 21:56 Don Cragun Relationship added related to 0000661
2019-06-02 22:12 Don Cragun Page Number unknown; don't have PDF => 180
2019-06-02 22:12 Don Cragun Line Number unknown; don't have PDF => 5945-5946
2019-06-02 22:12 Don Cragun Interp Status => ---
2019-06-28 14:28 geoffclare Note Added: 0004458
2019-06-28 14:29 geoffclare Relationship added related to 0001253
2019-06-28 17:10 shware_systems Note Added: 0004459
2019-07-15 15:24 geoffclare Final Accepted Text => Note: 0004458
2019-07-15 15:24 geoffclare Status New => Resolved
2019-07-15 15:24 geoffclare Resolution Open => Accepted As Marked
2019-07-15 15:24 geoffclare Tag Attached: issue8
2019-07-15 15:31 Don Cragun Relationship replaced has duplicate 0000661
2020-04-29 15:13 geoffclare Status Resolved => Applied
2024-06-11 09:08 agadmin Status Applied => Closed

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