Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001253 [1003.1(2016/18)/Issue7+TC2] Base Definitions and Headers Editorial Clarification Requested 2019-06-03 16:36 2019-10-24 08:29
Reporter eggert View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Applied  
Name Paul Eggert
Organization UCLA
User Reference https://mm.icann.org/pipermail/tz/2019-June/028043.html [^]
Section 8.3 Other Environment Variables - TZ
Page Number approximately 180 (sorry, don't have PDF)
Line Number approximately 5950 (sorry, don't have PDF)
Interp Status ---
Final Accepted Text See Note: 0004482
Summary 0001253: clarify that "alternative time" means tm_isdst is positive
Description In the tz mailing list (see, e.g., <https://mm.icann.org/pipermail/tz/2019-June/028043.html>) [^] there has been some confusion about the two terms "Daylight Savings Time" and "alternative timezone" used in Section 8.3 and elsewhere. The <time.h> section <http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html> [^] mimics wording from the C Standard and says "The value of /tm_isdst/ shall be positive if Daylight Savings Time is in effect, 0 if Daylight Savings Time is not in effect, and negative if the information is not available." However, Section 8.3 says that TZ defines "the designation for the standard (/std/) or the alternative (/dst/ -such as Daylight Savings Time) timezone", and this wording raises the question as to whether there is a difference between "alternative time" and "Daylight Savings Time".

I looked into the history of the POSIX wording. POSIX 1003.1-1988 section 8.1.1 says "the designation for the standard (/std/) or summer (/dst/) time zone". Evidently this used the British English "summer time" instead of the American English "Daylight Saving Time" used in the C standard. In popular usage the two phrases are equivalent; however, the American phrase is more technically accurate for POSIX since daylight saving time does not occur only in summer. At some point this discrepancy was fixed in POSIX by replacing "summer time" by "alternative time"; I suppose "alternative time" was used to avoid choosing sides between British and American English usage.

However, a problem in changing the POSIX wording from "summer (/dst/) time zone" to "the alternative (/dst/ -such as Daylight Savings Time) timezone" is that the revised wording raises the possibility that Daylight Savings Time is just one form of alternative time, and that the TZ string therefore does not govern which of the two designations (/std/ or /dst/) is in effect when the /tm_isdst/ flag is positive. In looking through the history of the standard, it's clear that the intent is for tm_isdst to be positive when /dst/ is used, and for tm_isdst to be zero when /std/ is used, but this intent is not completely clear in the current wording.

Another problem is that the phrase "alternative time" is used with a quite different meaning elsewhere in POSIX. For example, the strftime documentation says that %EX is "Replaced by the locale's alternative time representation", but this is talking about an alternative textual representation for timestamps, not about daylight saving time.

A simple way to avoid this confusion is to drop the term "alternative time", and to stick with the term "Daylight Saving Time" as used in the C standard. There is no technical reason to use two different terms, and the use of the "alternative time" term is causing unnecessary confusion.

One more thing: the normative spelling in English is "Daylight Saving Time" without an "s" at the end of "Saving". The C standard gets this right and POSIX should follow its lead.
Desired Action Change all uses of "Daylight Savings" to "Daylight Saving", everywhere in POSIX. Affected sections include <time.h>, mktime, tzset, strftime, and section 8.3 of the base definitions. I don't list these changes in detail here.

Drop the use of the term "alternative time", and stick with "Daylight Saving Time" as used in the C standard. In a quick search I found it used only in the Base Definitions section 8.3, so I propose the following changes to that section.

In section 8.3 Other Environment Variables - TZ, in the "/std/ and /dst" item, change from:

the alternative (/dst/ -such as Daylight Savings Time) timezone. Only /std/ is required; if /dst/ is missing, then the alternative time does not apply in this locale.

to:

the Daylight Saving (/dst/) timezone. Only /std/ is required; if /dst/ is missing, then Daylight Saving Time does not apply in this locale.


In the same section's "/offset/" item, change from:

If no /offset/ follows /dst/, the alternative time is assumed to be one hour ahead of standard time.

to:

If no /offset/ follows /dst/, Daylight Saving Time is assumed to be one hour ahead of standard time.


In the same section's "/rule/" item, change from:

Indicates when to change to and back from the alternative time.

to:

Indicates when to change from standard time to Daylight Saving Time, and when to change back.

Also, change from:

where the first date describes when the change from standard to alternative time occurs

to:

where the first date describes when the change from standard to Daylight Saving time occurs
Tags tc3-2008
Attached Files

- Relationships
related to 0001252Applied 1003.1(2016/18)/Issue7+TC2 Extend TZ to allow times outside 00-24 range, permanent DST 
related to 0001030Applied 1003.1(2013)/Issue7+TC1 The Single UNIX Specification says nothing about TZ environment variable settings without alternative time start or end 
related to 0001788Resolved 1003.1(2016/18)/Issue7+TC2 The meaning of "Daylight Saving Time" should be clarified 

-  Notes
(0004403)
Guy Harris (reporter)
2019-06-03 18:13
edited on: 2019-06-03 18:15

The mailing list link in the Description section doesn't work, at least on my browser - the > and ) following the link are appended to the link, so it ends with "%3F)".

The link is

    https://mm.icann.org/pipermail/tz/2019-June/028043.html [^]

(0004404)
Guy Harris (reporter)
2019-06-03 18:14
edited on: 2019-06-03 18:15

The Single UNIX Specification link in the Description section has a similar problem; it should

    https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html [^]

(0004405)
Guy Harris (reporter)
2019-06-03 19:01

Here's what provoked this request for interpretation:

In most locations that turn clocks forward in spring, so that there are more evening daylight hours and fewer morning daylight hours, and turn them backward in autumn, so that there are more morning daylight hours and fewer evening daylight hours, "standard time", as defined by law, is the time that's in effect when the clocks are *not* turned forward, so that "standard time" is in effect starting some time in autumn and ending some time in spring, and clocks are turned forward from standard time in spring and turned backward, reverting to standard time, in the autumn.

In the Republic of Ireland, however, as per section 1 of the Standard Time Act, 1968:

    http://www.irishstatutebook.ie/eli/1968/act/23/section/1/enacted/en/html#sec1 [^]

"The time for general purposes in the State (to be known as standard time) shall be one hour in advance of Greenwich mean time throughout the year, " and, as per section 1 of the Standard Time (Amendment) Act, 1971:

    http://www.irishstatutebook.ie/eli/1971/act/17/enacted/en/print#sec1 [^]

"Notwithstanding section 1 (1) of the Standard Time Act, 1968 , the time for general purposes in the State shall during a period of winter time be Greenwich mean time...", "The period beginning at two o'clock Greenwich mean time in the morning of the 31st day of October, 1971, and ending at two o'clock Greenwich mean time in the morning of the 19th day of March, 1972, shall for the purposes of this Act be a period of winter time.", and "Subject to subsection (2) of this section, the period beginning at two o'clock Greenwich mean time in the morning of the Sunday following the fourth Saturday in October in any year after 1971 and ending either at two o'clock Greenwich mean time in the morning of the Sunday following the third Saturday in the month of March in the following year or, if the last-mentioned Sunday is Easter Day, at two o'clock Greenwich mean time in the morning of the Sunday following the second Saturday in the month of March in that year shall for the purposes of this Act be a period of winter time"

So, in the Republic of Ireland, "standard time", as defined by law, is the time that's in effect when the clocks *are* turned forward, so that "standard time" is in effect *starting* some time in spring and *ending* some time in autumn, and clocks are turned forward *to* standard time in spring and turned backward, *from* standard time in the autumn.

According to the "Environment Variables" section of the Single UNIX Specification:

    https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html [^]

there are two "offset" fields in a TZ environment variable, which allows the first offset - the offset during the "standard timezone" - to be less than the second offset - the offset during what is currently referred to as the "alternative timezone", so that, for example, a setting such as

    XST-1GMT0,M10.5.0,M3.5.0/1

(similar to, but not identical to, a setting appropriate for the Republic of Ireland) is valid. With such a setting, should "tm_isdst" be set to 1 during the "standard timezone", when it could reasonably be argued that "Daylight Saving Time" is in effect, or should it be set to 1 during the "alternative timezone", when it could reasonably be argued that "Daylight Saving Time" is not in effect?

Another issue the raises is that the Single UNIX Specification page for tzset():

    https://pubs.opengroup.org/onlinepubs/9699919799/functions/tzset.html [^]

says that "The external variable timezone shall be set to the difference, in seconds, between Coordinated Universal Time (UTC) and local standard time." Presumably "local standard time" here is the time in the "standard timezone"; if so, that should be explicitly specified.
(0004460)
shware_systems (reporter)
2019-07-01 19:53

Alternative time is more accurate, technically, for the intent of the standard but to me is better termed as legislated time to distinguish it from alternative representation. The reason Daylight Saving is a misnomer is it is specific to how the US defines the procedure for changing clock settings and it doesn't take into account some region may decide they want to use something besides an hour forward to adjust the clock when the period begins.

For the Irish case, given the mathematics are the same, it doesn't matter that the statute calls STD time "winter time". This is more a matter of setting the TZ variable to reflect that's how they prefer to call it, e.g. IWT-1IST instead of something like IST-1IDT to match how the standard calls it; where I=Irish, W=Winter, S=Standard, D=Daylight, and T=Time for the acronyms, and matching on these to determine if tm_isdst should be zero, for winter time, or positive.

If anything the text could be more explicit that when tm_isdst is zero this refers to applying the offset from UTC using the value appropriate to the STD field, as expected to reflect contiguous seconds since the epoch at that point on the globe as solar time, with DST reflecting that there may be a missing or extra hour (or other period) in that contiguity due to a region adopting savings time of some type for the start and stop time of year provided. Whatever the difference in solar time was to local solar midnight when s-s-t-e was zero is effectively their standard time, for purposes of applying it to the TZ variable as a difference from UTC 12:00AM as the epoch's solar midnight, however it's referred to in other documents. This allows regions below the equator to define their legislated time as a period straddling day zero of a year, as their summer season begins with the December solstice, without conflicting with outside that period they go back to observing solar time.
(0004461)
Guy Harris (reporter)
2019-07-01 20:47
edited on: 2019-07-01 21:11

> Alternative time is more accurate, technically, for the intent of the standard but to me is better termed as legislated time to distinguish it from alternative representation.

Both standard and alternate time are "legislated time", in that legislation (or executive decrees) specify what time is considered "standard time" and what adjustments from standard time are made, so I don't think "legislated time" would be appropriate for "time adjusted from standard time".

> The reason Daylight Saving is a misnomer is it is specific to how the US defines the procedure for changing clock settings

"Daylight Saving" is a misnomer because daylight isn't "saved", it's shifted. But in what way is it specific to how the US defines the procedure?

> and it doesn't take into account some region may decide they want to use something besides an hour forward to adjust the clock when the period begins.

"Daylight Saving" implies nothing about the amount of the adjustment, just that there's an adjustment to "save" daylight time. That's generally read as "shift daylight time from the morning to the evening", which isn't US-specific.

> For the Irish case, given the mathematics are the same, it doesn't matter that the statute calls STD time "winter time".

The statute calls the time from somewhere in October to somewhere in March "winter time"; it makes no reference to UNIX's TZ environment variable. A question being raised here is whether "STD time" refers to "standard time as specified by legislation", in which case that would be summer time in Ireland, or to "the time when clocks aren't turned forward to move daylight time from the morning to the evening", in which case that would be winter time in Ireland.

And winter time in Ireland is GMT, so the setting would be IST-1GMT0... for the appropriate value of "...", if the intent is that "STD time" refers to "standard time as specified by legislation", or GMT1IST0... if the intent is that "STD time" refers to "the time when clocks aren't turned forward to move daylight time from the morning to the evening".

> If anything the text could be more explicit that when tm_isdst is zero this refers to applying the offset from UTC using the value appropriate to the STD field, as expected to reflect contiguous seconds since the epoch at that point on the globe as solar time,

Yes, the TZ environment variable specification in the POSIX spec does seem to assume that a given point on the globe never switches from one time zone to another, so that might work in that context. That's also a reason why many systems use the tzdb, which doesn't impose that restriction.

What, if anything, does the page for <time.h> dictate for systems where TZ is, for example, set to ":Europe/Minsk", on a system where that refers to the tzdb region Europe/Minsk, which covers a region that switched from GMT+1, with Central European DST rules, to GMT+3, with Russian DST rules, in 1990? As the the characters in TZ following the colon are handled in "an implementation-dependent manner", is it also implementation-dependent what tm_isdst means, so that the sample code going with the tzdb can set it as it chooses without violating the Single UNIX Specification?

> with DST reflecting that there may be a missing or extra hour (or other period) in that contiguity due to a region adopting savings time of some type for the start and stop time of year provided.

So "savings time of some type" could mean "turning the clock forward" *or* "turning the clock backward", as per, for example, IST-1GMT...?

(0004482)
nick (manager)
2019-07-15 15:19

Change all uses of "Daylight Savings" to "Daylight Saving", everywhere in POSIX:
Page 425 lines 14450-14452:
    Change "Daylight Savings" to "Daylight Saving"
    
Page 729 line 24832:
    Change "Daylight Savings" to "Daylight Saving"

Page 1331 lines 44310-44312:
      Change "Daylight Savings" to "Daylight Saving"

Page 2047 line 65622
    Change "daylight savings" to "daylight saving"

Page 2185 line 69922:
      Change "Daylight Savings" to "Daylight Saving"

Drop the use of the term "alternative time" in the description of the TZ environment variable, and stick with "Daylight Saving Time" as used in the C standard.
In section 8.3 Other Environment Variables - TZ, in the "std and dst" item, change page 179 line 5891 from:
the alternative (dst -such as Daylight Savings Time) timezone. Only std
 is required; if dst is missing, then the alternative time does not apply in this locale.


to:

the Daylight Saving (dst) timezone. Only std is required; if dst is missing,
then Daylight Saving Time does not apply in this locale. Note: The usage of the terms
"Standard Time" and "Daylight Saving Time" is not necessarily related to any legislated timezone.



In the same section's "offset" item, change page 179 line 5916 from:

If no offset follows dst, the alternative time is assumed to be one hour ahead
of standard time.


to:

If no offset follows dst, Daylight Saving Time is assumed to be one hour ahead
of standard time.



In the same section's "rule" item, change page 180 line 5925 from:

Indicates when to change to and back from the alternative time.


to:

Indicates when to change from standard time to Daylight Saving Time, and when to
change back.


Also, change line 5928 from:

where the first date describes when the change from standard to alternative time
occurs and the second date describe when the change back happens.


to:

where the first date describes when the change from standard to Daylight Saving
time occurs and the second date describes when it ends; if the second date is specified
as earlier in the year than the first, then the year begins and ends in Daylight Saving time.

- Issue History
Date Modified Username Field Change
2019-06-03 16:36 eggert New Issue
2019-06-03 16:36 eggert Name => Paul Eggert
2019-06-03 16:36 eggert Organization => UCLA
2019-06-03 16:36 eggert User Reference => https://mm.icann.org/pipermail/tz/2019-June/028043.html [^]
2019-06-03 16:36 eggert Section => 8.3 Other Environment Variables - TZ
2019-06-03 16:36 eggert Page Number => approximately 180 (sorry, don't have PDF)
2019-06-03 16:36 eggert Line Number => approximately 5950 (sorry, don't have PDF)
2019-06-03 18:13 Guy Harris Note Added: 0004403
2019-06-03 18:14 Guy Harris Note Added: 0004404
2019-06-03 18:15 Guy Harris Note Edited: 0004403
2019-06-03 18:15 Guy Harris Note Edited: 0004404
2019-06-03 19:01 Guy Harris Note Added: 0004405
2019-06-08 01:41 Guy Harris Issue Monitored: Guy Harris
2019-06-28 14:29 geoffclare Relationship added related to 0001252
2019-07-01 19:53 shware_systems Note Added: 0004460
2019-07-01 20:47 Guy Harris Note Added: 0004461
2019-07-01 21:11 Guy Harris Note Edited: 0004461
2019-07-15 15:19 nick Note Added: 0004482
2019-07-15 15:19 nick Note Added: 0004483
2019-07-15 15:20 nick Note Deleted: 0004483
2019-07-15 15:21 nick Interp Status => ---
2019-07-15 15:21 nick Final Accepted Text => See Note: 0004482
2019-07-15 15:21 nick Status New => Resolved
2019-07-15 15:21 nick Resolution Open => Accepted As Marked
2019-07-15 15:21 nick Tag Attached: tc3-2008
2019-10-23 09:39 geoffclare Relationship added related to 0001030
2019-10-24 08:29 geoffclare Status Resolved => Applied
2023-11-20 01:04 Don Cragun Relationship added related to 0001788


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