Hide Forgot
Description of problem: Trying to list time changes using zdump, it prints wrong abbreviation for the reference time - "UT" is printed while there should be "UTC". Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. zdump -v America/Santiago | grep 2016 Actual results: America/Santiago Sun May 15 02:59:59 2016 UT = Sat May 14 23:59:59 2016 CLST isdst=1 gmtoff=-10800 America/Santiago Sun May 15 03:00:00 2016 UT = Sat May 14 23:00:00 2016 CLT isdst=0 gmtoff=-14400 America/Santiago Sun Aug 14 03:59:59 2016 UT = Sat Aug 13 23:59:59 2016 CLT isdst=0 gmtoff=-14400 America/Santiago Sun Aug 14 04:00:00 2016 UT = Sun Aug 14 01:00:00 2016 CLST isdst=1 gmtoff=-10800 Expected results: America/Santiago Sun May 15 02:59:59 2016 UTC = Sat May 14 23:59:59 2016 CLST isdst=1 gmtoff=-10800 America/Santiago Sun May 15 03:00:00 2016 UTC = Sat May 14 23:00:00 2016 CLT isdst=0 gmtoff=-14400 America/Santiago Sun Aug 14 03:59:59 2016 UTC = Sat Aug 13 23:59:59 2016 CLT isdst=0 gmtoff=-14400 America/Santiago Sun Aug 14 04:00:00 2016 UTC = Sun Aug 14 01:00:00 2016 CLST isdst=1 gmtoff=-10800 Additional info: UTC is the base time used for time zone definitions - see https://en.wikipedia.org/wiki/Coordinated_Universal_Time#Uses In addition, using just "UT" is not enough because there is no single "universal time", but rather several flavours with different abbreviations ("UTC" being one of them) - see https://en.wikipedia.org/wiki/Universal_Time#Versions
Upstream tzcode zdump.c also uses "UT", therefore we are not going to change this until upstream tzcode changes and we synchronize with them. I've reached out to upstream to discuss this issue.
ah, ok, I could have realised where to look so I have traced it to commit 42801d2b1fb0a644096c228daec1be20278d9bd0 Correct some UTC-vs-UT solecisms. In several places the code and documentation incorrectly used "UTC" to describe time stamps that might precede the introduction of UTC and for which UTC is therefore undefined. Change these uses to "UT", as that's the correct term when talking about these time stamps. Problem reported by Steve Allen in <http://mm.icann.org/pipermail/tz/2013-September/019907.html>. The major compatibility issue here is with 'zdump -v'; it'll now output "UT" instead of the possibly-incorrect "UTC". Many files change in minor ways in the commentary. * zdump.c (show): * zic.c (inzsub, addtype): In output, say "UT" rather than "UTC", since the time stamp we're talking about might precede the introduction of UTC. um, oh, well ... I just don't understand that - please correct me if I'm wrong: the patch is intended to fix the output for timestamps before 1960 when UTC was defined but it doesn't check for the date of introduction of UTC, so the consequence is that it actually *breaks* the output for timestamps after 1960 - or after 1972 when it was changed to its current form reading further about history, from 1928[1] (or 1935[1]) to 1960, the term "Universal Time" was not ambiguous, and it meant "civil GMT" which has been introduced in 1847 so, the original situation before the patch was: big bang-1960: not existing "UTC" referred 1960-1972: existing, but maybe wrongly computed UTC referred 1972-now: UTC referred correctly after the patch: big bang-1847: not existing, undefined "UT" referred 1847-1928 (or 1935): not existing UT referred but might be computed using "civil GMT" 1928 (or 1935)-1960: UT referred correctly 1960-1972: UT is ambiguous[3] and might be computed incorrectly due to discrepancy between SI and astronomical second 1972-now: UT is ambiguous and it is *always* referred incorrectly as last country switched to UTC in 1972 to me, it doesn't seem like an improvement; well, in fact, as vast majority of tzdata usage concerns the present, not the past (and especially not the past before "The Unix Epoch" which is defined explicitly using UTC), I see that rather as a major breakage ... [1] according to the article on UTC [2] according to the article on UT [3] note that the original series of emails from Steve Allen does mention that in 1963, "UT2" and *not* "UT" was used by CCIR, for example, so the patch is wrong even for the thing it should have fixed by its own reference!
"UT" is deliberately nonspecific, as "UTC" is incorrect for time stamps before 1960 whereas the vaguer "UT" is correct both for time stamps before and after 1960. UTC was introduced in 1960 and is not defined for earlier time stamps.
pardon my ignorance, but still I do not know how does the fact that UTC was undefined until 1960 justify using wrong (or "deliberately nonspecific") base for records after 1972 - especially considering the fact that "UT" itself is not defined for time stamps earlier than 1928 (or 1935), i.e. has exactly the same problem ...?[*] I know we're just downstream here, but accepting this upstream change brings regression to our customers - the output that was correct at least for recent dates is changed to output that is incorrect for recent dates and correct just for a short period in the past (between 1928 or 1935 and 1960, see comment #3) is it really that problematic to change the code to have something like if year > 1960 then print "UTC" else print "UT"? [*] the original mailinglist thread about the change says "Unlike UTC, the concept of UT can be validly extended into the indefinite past." - but this is false argument, because UTC is based on TAI, which is simple (ahem) physics that works both into the future and into the past, with corrections (leap seconds) to be close to UT1, which was said to be extendable into the past, so UTC is no less extendable into the past than UT (or "UT1")
(In reply to Karel Volný from comment #6) > I know we're just downstream here, but accepting this upstream change brings > regression to our customers - the output that was correct at least for > recent dates is changed to output that is incorrect for recent dates and > correct just for a short period in the past (between 1928 or 1935 and 1960, > see comment #3) Do you have a specific example where the change creates a regression and the wrong date is computed from output of zdump or the output of APIs that manipulate the data?
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
No response in over six months, re-closing as NOTABUG.
(In reply to Florian Weimer from comment #9) > No response in over six months, re-closing as NOTABUG. sorry, I missed that in the bugzilla 'spam' during all the RHSCL rush last year :-( (In reply to Carlos O'Donell from comment #7) > Do you have a specific example where the change creates a regression and the > wrong date is computed from output of zdump or the output of APIs that > manipulate the data? I do not understand the question - I am not talking about wrong date computed, I am talking about outputting "UT" instead of "UTC" ... it is even described as such in the commit I refer to in comment #3
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
We will not deviate from upstream for this. I agree that changing UTC to UT was an unnecessary change, but I don't want to introduce persistent cross-distribution variance here.