Bug 1328525

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.

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.

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