Austin Group Defect Tracker

Aardvark Mark III


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001253 [1003.1(2016)/Issue7+TC2] Base Definitions and Headers Editorial Clarification Requested 2019-06-03 16:36 2019-06-03 19:01
Reporter eggert View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
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
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 No tags attached.
Attached Files

- Relationships

-  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.

- 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


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