A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=1788 ====================================================================== Reported By: Guy Harris Assigned To: ====================================================================== Project: 1003.1(2016/18)/Issue7+TC2 Issue ID: 1788 Category: Base Definitions and Headers Type: Clarification Requested Severity: Comment Priority: normal Status: New Name: Guy Harris Organization: User Reference: Section: N/A Page Number: N/A Line Number: N/A Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2023-11-18 00:16 UTC Last Modified: 2023-11-20 17:10 UTC ====================================================================== Summary: The meaning of "Daylight Saving Time" should be clarified ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- related to 0001253 clarify that "alternative time&quo... ======================================================================
---------------------------------------------------------------------- (0006576) kre (reporter) - 2023-11-20 17:10 https://austingroupbugs.net/view.php?id=1788#c6576 ---------------------------------------------------------------------- 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. Issue History Date Modified Username Field Change ====================================================================== 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 ======================================================================
