|Anonymous | Login||2023-03-31 00:24 UTC|
|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||2020-04-29 15:13|
|Priority||normal||Resolution||Accepted As Marked|
|Section||8.3 Other Environment Variables - TZ|
|Final Accepted Text||Note: 0004458|
|Summary||0001252: Extend TZ to allow times outside 00-24 range, permanent DST|
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.
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.
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".
Assuming bug 0001253 is accepted, the changes should be ...
On page 280 line 5945 section 8.3, change:
to:The time has the same format as offset except that no leading sign ('-' or '+') is allowed.
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".
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.
|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|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|