|Anonymous | Login||2023-12-02 09:37 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0001788||[1003.1(2016/18)/Issue7+TC2] Base Definitions and Headers||Comment||Clarification Requested||2023-11-18 00:16||2023-11-30 22:57|
|Reporter||Guy Harris||View Status||public|
|Final Accepted Text|
|Summary||0001788: The meaning of "Daylight Saving Time" should be clarified|
The term "Daylight Saving Time" is used in a number of places in the specification.
In much of the world, it refers to the time during the summer when clocks are turned forward from standard time.
However, in some locations, such as Ireland, "standard time" is observed during the summer, and the clocks are turned backward during the winter. At least some web sites in Ireland refer to "Daylight Saving Time" as the time when clocks are not turned backward. Furthermore, in Namibia, a change was made to turn clocks backward during the winter, and at least one news site referred to the time when clocks are turned backward as "Daylight Saving Time".
This could lead different readers of the specification to reach different conclusions as to what is done to clocks when Daylight Saving Time is in effect.
The specification of the TZ environment variable in section 8.3 Other Environment Variables allows the UTC offset if Daylight Saving Time is in effect either to be more than or less than the UTC offset if Daylight Saving Time, so it appears that the intent is to allow Daylight Saving Time either to be "summer time" or "winter time".
The document should, at minimum, explicitly state that, if Daylight Saving Time is in effect, the clock may have its offset from UTC either be more than, or less than, its offset from UTC when Daylight Saving Time is not in effect.
Ideally, it should either define, in some fashion, what "standard time" and "Daylight Saving Time" are, or explicitly indicate that the meaning is either implementation-defined or undefined, so that code makes no invalid assumptions about, for example, the significance of the tm_isdst member of a struct tm being set to a positive value by localtime().
|Tags||No tags attached.|
|Attached Files||grep-over-bsds.txt [^] (5,697 bytes) 2023-11-23 23:21|
Don Cragun (manager)
Much of this seems to be duplicated in Guy's notes on 0001253 (Note: 0004405, Note: 0004460, and Note: 0004461).
Changes related to that bug have already been incorporated into Issue 8 draft 3.
The changes that are incorporated from 1253 are a part of the problem.
The issue is that POSIX is not defining the phrase "Daylight Saving Time",
which means that it is falling back on the normal English meaning of the
The problem is that there isn't one - depending upon your view of the
subject, and your culture, "Daylight Saving Time" means different things
to different people.
To some, it just means the "alternate" time as is used in the current
published standard. To Guy (based upon what I have read from a different
mailing list, from whence this bug report originated), "Daylight Saving Time"
means (and only means) the time in effect during the (mostly) summer months
when the offset from UTC is advanced from what is considered standard time.
Nothing else counts as DST in that view (and a locality where standard time
is in force in the summer, and time is set backwards to winter time for
a period, cannot, in this view of things, be said to have DST - but
To me (and others) anything which puts the words "daylight" and "saving"
(or the worse "savings") in adjacent positions (in either order) in anything
simply turns whatever that is into a joke. The phrase is an absurd
All this bug is doing is requesting that the phrase be defined by POSIX
so its meaning within the standard is clarified, and not depending on
people's views of what it means (or should mean).
While doing that the phrase "standard time" should be defined as well.
In reality, standard time is the time that applies in a locality.
That's it. That is in England now, it is GMT. In 6 months it will be
BST. Both are the standard time for England, during different periods
of the year -- if the clock tower at Westminster says the time is xx:yy,
that is the standard time (right then) for the realm - perhaps give or
take a few seconds, I don't know how accurate that clock is.
But that is not the way it is used in POSIX.
In the standard, the names are used for the two (assumed to be all that
can exist) offsets from UTC that a locality observes during a year, with
the assumption that each year there is one transition from standard time
to daylight saving time, and one transition from daylight saving time to
standard time, which can occur each year (in either order). (Of course
a locality can also have no transitions and remain on its standard time
all year - the situation where the name "standard time" is actually used
appropriately - but that case is not the interesting one.)
That's all the phrases are used for in POSIX - there's no special attribution
given to one period over the other, no additional hidden meanings, they're
just labels being used to indicate that there might be these two different
offsets, and we need to be able to refer to them mto configure them properly.
Of course, the model upon which this is based is fundamentally flawed,
nothing says there will be just zero or two transitions during a year,
some localities have had 1 during some years (ie: simply shifted their
offset) others have 4, switching backwards between the two offsets twice
during the year is one case, another is switching between 3 different
offsets during the year (from A to B to C to B to A is one possibility,
that one has 4 transitions, but A to B to C to A is another (with just 3)
and there are a myriad of other possibilities.
That's why the old POSIX TZ string (the thing which primarily uses the
standard and daylight saving distinction) is essentially useless, and
no-one seriously uses it any more. That, and that it can only specify
the current transition algorithm, not any previous one - so when a locality
changes its rules for the transitions, updating the TZ string allows
current and future times to be converted from the underlying UTC timestamps
correctly (and vice versa when required) but completely botches the
translations of timestamps from, previous years, when the transition rules
When using the new form of TZ specification, none of this matters, as with
that, nothing in POSIX is required any more to divide local time into those
two camps (a very good thing to have happened).
That is, except for tm_isdst. That's the one remaining anachronism.
As an output from localtime() it is completely useless now, as it can
only be 0 or 1 there, which permit just "no" and "yes" answers to
whatever question it is supposed to be answering, and that's simply
insifficient for anything. In that context it should simply be marked
as deprecated, and allowed to wither (applications should be advised to
simply ignore it).
Its other use is as input to mktime() - a use for which it is entirely
inadequate, as a tri-state (unknown, no, yes) cannot possibly express
the possibilities. Unfortunately for this we do not yet have an
alternative, and for most purposes, its value is irrelevant (and should
be given as -1 ("unknown") as mktime() input.) The actual time to be
converted in the remaining fields, along with the location's transition
rules (however complicated they are) are sufficient to calculate the
desired outcome. For the few cases where that is not true, using one of
the other two allow inputs in this field (0 or >0) is inadequate to cover
the possibilities, that it happens to work OK in the parts of the world
who contribute people to these groups is perhaps no coincidence, but
doesn't make it sensible.
So, my preferred solution to this issue would be to remove all mentions of
both standard time and daylight saving time, and just call them offsetA and
offsetB (not 1 and 2 as we want to be able to have numbers immediately
after, and that would confuse things) while at the same time noting that
this model is not adequate, and should not be used any more. tm_isdst
should be listed as unspecified on output from localtime(), so applications
cannot sensibly use it for anything. mktime() should probably just be
abandoned (until replaced by something with an interface that works).
But I don't seriously expect that to happen, even though it would give the
best outcome. At the very least though, there need to be definitions of
the terms, to mean what POSIX intends them to mean, certainly do not rely
upon some common understanding of them - there isn't one.
Guy Harris (reporter)
One use for tm_isdst as an output from localtime() would be to choose which element of tzname is the right time zone abbreviation for the time that was converted.
However, neither the current standard nor Draft 3 appears to state, specifically, that tzname[tm->tm_isdst] is the right time zone name; that's merely suggested by the contents of the sections describing tzname, time.h, and the TZ environment variable. I think that's the intention of the people at AT&T who originally provided it, but that doesn't suffice for a specification.
In systems that support tm_zone as a member of struct tm, using that is preferable; perhaps the 202x standard should not only require tm_zone and tm_gmtoff, but deprecate tm_isdst, tzname, timezone, and daylight in favor of those fields. Those fields don't let you find out whether "Daylight Saving Time is in effect", but, given that "Daylight Saving Time" is not defined by the standard, it's not clear that finding out whether Daylight Saving Time is in effect provides any information that's useful if you already know the UTC offset and time zone abbreviation name.
Guy Harris (reporter)
The IETF RFC 8536, "The Time Zone Information Format (TZif)", which describes the format of the compiled files generated by the IANA time zone database's zic command from the time zone database source files, says, in the Conventions Used in This Document section:
The following terms are used in this document (see "Sources for Time
Zone and Daylight Saving Time Data" [tz-link] for more detailed
information about civil timekeeping data and practice):
Daylight Saving Time (DST): The time according to a location's law
or practice, when adjusted as necessary from standard time. The
adjustment may be positive or negative, and the amount of
adjustment may vary depending on the date and time; the TZif
format even allows the adjustment to be zero, although this is not
Standard Time: The time according to a location's law or practice,
unadjusted for Daylight Saving Time.
tm_isdst has a defined negative value, too. Other than that it "shall be positive" according to the current draft, or 0.
So the indexing thing at least seems hypothetic.
|Btw one instance of extern char *tzname; and one of extern char *tzname; in the draft. While maybe acceptable on C level, the standard should possibly use identical definitions.|
Guy Harris (reporter)
So indexing won't work, and it would have to be more like
if (tm->tm_isdst == 0)
time_zone_abbreviation = tzname;
else if (tm->tm_isdst > 0)
time_zone_abbreviation = tzname;
time_zone_abbreviation = NULL; /* abbreviation is unknown */
If i grep(1) through (Free|Net|Open)BSD your use case seems superficial.
In general people seem to go through time functions instead of direct additions.
The file list below over all three is 153 lines for
git grep tzname BRANCH |
grep -vEi 'makefile|configure|tzcode|tzdata|/man/' |
sed -Ee 's/.+:(.+):.*/\1/' |
with many "false positives" still (and matches like libc/time).
The python and perl languages i also looked at (perl also included in the list through OpenBSD though, .. a bit) have some use cases, like Perl's POSIX module.
Ie snake bites its own tail, practically.
I see no usage of tzname in the servers i use for email, http, ssh, nor in the openssh library.
In general i think what should be strived for is a reentrant ie multithread-aware interface where global constants and all the inter-dependencies the current interface has, with all its complicated rules, are not used at all.
Simply obsoleting tzname and such from now at a moment's notice is a bit rigid.
I agree it is very unfortunate that localtime and such need to set tzname etc.
Guy Harris (reporter)
> If i grep(1) through (Free|Net|Open)BSD your use case seems superficial.
If by "superficial" you mean "unnecessary in most cases", that's probably true, as most programs don't need to report time zone abbreviations.
However, some programs do, which is why system provide either tzname or tm_zone at all.
> In general people seem to go through time functions instead of direct additions.
In general I suspect programs don't report time zone abbreviations.
And the BSDs all provide tm_zone, so programs that are part of those OSes, and that need to report the time zone abbreviation, don't need to look at tzname *anyway*.
But, if you need a time zone abbreviation, it's hard to go through a time function if there *is* no time function that returns a time zone abbreviation, as is the case on some UN\*Xes such as Solaris 2+/SunOS 5.x (which probably has it because AT&T wouldn't allow tm_zone into struct tm in SVR4 because it might break binary compatibility with SVR3; SunOS 4.x had tm_zone because it was added when tzdb support was put into 4.0). Systems *with* tm_zone can use localtime() to get the time zone abbreviation.
> The python and perl languages i also looked at (perl also included in the list through OpenBSD though, .. a bit) have some use cases, like Perl's POSIX module.
They presumably use tzname when they run on those UN*Xes that don't have tm_zone. Perhaps on those systems that do, they use that instead.
> I see no usage of tzname in the servers i use for email, http, ssh, nor in the openssh library.
Most of them probably either 1) don't need to report time zone abbreviations or 2) rely on strftime() to provide it.
> In general i think what should be strived for is a reentrant ie multithread-aware interface where global constants and all the inter-dependencies the current interface has, with all its complicated rules, are not used at all.
Such as localtime_r() with tm_zone in struct tm, which is what POSIX 202x Draft 3 appears to require, except that "If the tm structure member tm_zone is accessed after the value of TZ is subsequently modified, the behaviour is undefined." For most if not all cases where TZ is modified, something such as NetBSD localtime_rz - https://man.netbsd.org/ctime.3 [^] - would handle this.
> Simply obsoleting tzname and such from now at a moment's notice is a bit rigid.
"obsoleting" is a less precise term than "deprecating", which is the term I used in my comment.
If "obsoleting" means "recommending that something else be used, if possible", which I would (and did) call "deprecating", I seee nothing rigid at all about recommending that code that only needs to run on systems supporting POSIX 202x, and allowing code that needs to run on pre-POSIX-202x systems that lack tm_zone in struct tm.
If "obsoleting" means "removing from POSIX, so that POSIX 202x systems need not provide it", *that* is too rigid, and it's also not anything that I recommended.
(I had attached the file which Mantis did not seem to report.)
Regarding perl: i had the impression they simply provide the symbol and need to manage it thus.
Yes: i agree that localtime_rz() and consorts is what the standard would really need (in conjunction with tzalloc() etc).
I recall on the IANA tz list Christos Zoulas (and Robert Elz?) of NetBSD spoke up in this regard, but Paul Eggert then "did something else". Or at least slightly different. It surely was already some years ago.
Hmm. From a short glance TZ equals in prototype(s) the "trunk" branch of NetBSD. We have TZ expert here (you are one, actually :) who know much better.
Since IANA TZ code is used so widely and Public Domain for anyone, it would surely be a good decision to include it already in the next standard, instead of waiting longer.
Someone who can should sponsor this mature code for inclusion right away.
P.S., @Guy Harris: is it you who will open the request for tzalloc and consorts, localtime_rz, and mktime_z, and posix2time_z and time2posix_z?
From looking at the changelog the code landed (as a joint effort if i recall correctly) in 2014g (2014-08-28) of the public domain IANA TZ code.
The core developers will not (be allowed to) do anything unless there is an official work request issued.
I repeat that i think that these would be fantastic additions to POSIX, they allow for real multithreading, or, simply, code isolation.
In hindsight to the code snippet of the chrony NTP daemon posted on the IANA TZ list the improvement cannot be overestimated, in my opinion.
(Manual pages aka reference documentation is also completely available as public domain via IANA TZ.)
|2023-11-18 00:16||Guy Harris||New Issue|
|2023-11-18 00:16||Guy Harris||Name||=> Guy Harris|
|2023-11-18 00:16||Guy Harris||Section||=> N/A|
|2023-11-18 00:16||Guy Harris||Page Number||=> N/A|
|2023-11-18 00:16||Guy Harris||Line Number||=> N/A|
|2023-11-20 01:03||Don Cragun||Note Added: 0006573|
|2023-11-20 01:04||Don Cragun||Relationship added||related to 0001253|
|2023-11-20 17:10||kre||Note Added: 0006576|
|2023-11-22 19:40||Guy Harris||Note Added: 0006583|
|2023-11-22 20:12||Guy Harris||Note Added: 0006584|
|2023-11-22 20:35||steffen||Note Added: 0006585|
|2023-11-22 20:37||steffen||Note Added: 0006586|
|2023-11-22 21:07||Guy Harris||Note Added: 0006587|
|2023-11-23 23:19||steffen||Note Added: 0006588|
|2023-11-23 23:21||steffen||File Added: grep-over-bsds.txt|
|2023-11-24 02:46||Guy Harris||Note Added: 0006589|
|2023-11-25 21:28||steffen||Note Added: 0006590|
|2023-11-30 16:17||nick||Relationship added||parent of 0001779|
|2023-11-30 16:19||nick||Relationship deleted||parent of 0001779|
|2023-11-30 22:57||steffen||Note Added: 0006594|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|