 Notes |
(0006573)
Don Cragun (manager)
2023-11-20 01:03
|
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. |
|
(0006576)
kre (reporter)
2023-11-20 17:10
|
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
phrase.
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
something different).
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
construction.
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
were different.
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. |
|
(0006583)
Guy Harris (reporter)
2023-11-22 19:40
|
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. |
|
(0006584)
Guy Harris (reporter)
2023-11-22 20:12
|
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
common practice.
...
Standard Time: The time according to a location's law or practice,
unadjusted for Daylight Saving Time. |
|
(0006585)
steffen (reporter)
2023-11-22 20:35
|
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. |
|
(0006586)
steffen (reporter)
2023-11-22 20:37
|
Btw one instance of extern char *tzname[2]; and one of extern char *tzname[]; in the draft. While maybe acceptable on C level, the standard should possibly use identical definitions. |
|
(0006587)
Guy Harris (reporter)
2023-11-22 21:07
|
So indexing won't work, and it would have to be more like
if (tm->tm_isdst == 0)
time_zone_abbreviation = tzname[0];
else if (tm->tm_isdst > 0)
time_zone_abbreviation = tzname[1];
else
time_zone_abbreviation = NULL; /* abbreviation is unknown */ |
|
(0006588)
steffen (reporter)
2023-11-23 23:19
|
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/' |
uniq
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. |
|
(0006589)
Guy Harris (reporter)
2023-11-24 02:46
|
> 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. |
|
(0006590)
steffen (reporter)
2023-11-25 21:28
|
(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. |
|
(0006594)
steffen (reporter)
2023-11-30 22:57
|
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.)
Thank you. |
|
(0006617)
geoffclare (manager)
2024-01-08 17:50
|
The discussions in teleconferences are leaning towards adding the definitions from RFC 8536 (as per Note: 0006584), suitably adapted for POSIX. However, the question has also arisen of whether further changes should be made to acknowledge the limitation of the historical tzname[] and tm_isdst interfaces to cater for more than two timezone names.
One suggestion is to mark the tzname[] array obsolescent (in Issue 8 TC1) and advise applications to obtain timezone names from either the tm_zone structure member or the strftime() %Z conversion instead.
Another suggestion is that the standard could allow tzname[] to have more than 2 entries, but the question arose as to whether this is something that any implementation would want to do (or even has done already). Code from before the C standard used the tm_isdst returned by localtime() as an index for tzname[], and such code would "work" with more than two zone names. Later code is unlikely to have done this because the C standard said any positive tm_isdst value means DST is in effect (and thus in the context of POSIX, the zone name would be tzname[1]). So it is not clear how much benefit to applications there would be if an implementation were to make that change. The only thing stopping it at the moment is the definition as "extern char *tzname[2]" given on the tzset() page; the minimum change needed would be just to remove that "2".
We would welcome any feedback on these suggestions. |
|
(0006618)
steffen (reporter)
2024-01-08 19:55
|
I cannot imagine anyone is looking forward for "more than 2 entries", to be honest.
In the wild you see binary code use cases like "tzname[t->tm_isdst != 0][0] == '-'", and that is the IANA TZ code.
In real life datetime needs to be accompanied with a calendar, in fact the entire ISO C and also POSIX interface is only by sheer luck, and by politeness and obligingness, usable for anything non-blue-eyeish and blonde, so to say; a bit exaggerated surely.
I think direct access should be "obsoleted".
In fact i think what i read here for strftime(3):
[.] that of the E modifier is to use a locale‐dependent alter‐
native representation. The rules governing date representation with
the E modifier can be obtained by supplying ERA as an argument to a
nl_langinfo(3). One example of such alternative forms is the Japanese
era calendar scheme in the ja_JP glibc locale.
endorsed. Also for myself :( |
|
(0006619)
geoffclare (manager)
2024-01-11 16:44
|
Add the following to the definitions in XBD chapter 3 putting them in alphabetical order and renumbering moved definitions.
3.xxx Daylight Saving Time (DST)
The time according to a location's law or practice, when adjusted as necessary from standard time. The adjustment can be positive or negative, and the amount of adjustment can vary depending on the date and time; the adjustment can even be zero, although this is not common practice.
<small>Note: timezone information can be supplied via the TZ environment variable, which is defined in detail in [xref to XBD 8.3]</small>.
See also [xref to 3.yyy Standard Time].
3.yyy Standard Time
The time according to a location's law or practice, unadjusted for Daylight Saving Time.
<small>Note: timezone information can be supplied via the TZ environment variable, which is defined in detail in [xref to XBD 8.3]</small>.
See also [xref to 3.xxx Daylight Saving Time]. |
|
(0006620)
geoffclare (manager)
2024-01-11 16:53
|
In the January 11, 2024 teleconference it was decided that the resolution of this bug should just address the missing definitions. Any additional changes related to tzname[] etc. should be the subject of a separate bug. |
|
grep-over-bsds.txt [^] (5,697 bytes) 2023-11-23 23:21 
