GNU bug report logs - #79261
coreutils 9.7 "date -u" - timezone offset is in the wrong direction

Previous Next

Full log

View this message in rfc822 format

From: James Feeney <james <at> nurealm.net>
To: martin <at> kurahaupo.gen.nz, 79261 <at> debbugs.gnu.org
Subject: bug#79261: coreutils 9.7 "date -u" - timezone offset is in the wrong direction
Date: Mon, 25 Aug 2025 15:15:06 -0600

Hey Martin

On Mon, 2025-08-25 at 20:10 +1000, Martin D Kealey wrote:
> Hi James
> 
> On Mon, 25 Aug 2025, 07:33 James Feeney via GNU coreutils Bug Reports, <bug-coreutils <at> gnu.org> wrote:
> > it must also be noted that "UTC" is in *Great Britain*, 
> 
> To be honest, referring to UTC as "in" Britain is pretty weird. UTC may be used in Great Britain, but it's also used in Burkina Faso, Canary Islands, Côte d'Ivoire, Danmarkshavn, Faroe Islands, Gambia, Ghana, Guinea, Guinea-Bissau, Iceland, Ireland, Liberia. Mali, Mauritania, Portugal, São Tomé and Príncipe, Senegal, Sierra Leone, & Togo.
> 
> If this is motivated by geography, it's worth considering that less than 5% of the length of the  Greenwich Meridian is actually within the bounds of the British Isles.
> 
> We in the rest of the world don't think at all about Britain when we hear or mention UTC (or GMT).
> 
> TL;DR locale and timezone are independent; neither implies the other.
> 
> -Martin

Thanks for your note.  Short version: your point is taken, and I submit a revised argument, an appeal to ISO 8601.

My essential question is this:  What is the "proper" time *display format* for "UTC"?

And just to be clear, referencing https://www.timeanddate.com/time/gmt-utc-time.html

    UTC is a time standard officially used to determine the civil time in time zones worldwide.
    GMT is a time zone observed in some European and African countries.

UTC itself is a bit complicated to understand because of the many different methods used to define "time".

Referencing https://www.itu.int/hub/2023/07/coordinated-universal-time-an-overview/
----
Coordinated Universal Time (UTC) is the worldwide reference time scale computed by the Bureau international des poids et mesures (BIPM).
UTC is based on about 450 atomic clocks, which are maintained in 85 national time laboratories around the world.

The International Earth Rotation and Reference Systems Service (IERS) determines and publishes the difference between UTC and the Earth rotation angle indicated by UT1. Whenever this difference approaches 0.9 seconds, a new leap second is announced and applied in all time laboratories.

BIPM first computes a weighted average of all the designated atomic clocks to achieve International Atomic Time (TAI). The algorithm for computing TAI is complex, involving estimation, prediction and validation for each type of clock.

Similarly, measurements to compare clocks at distance are based either on global navigation satellite systems (GNSS) or on other techniques, such as two-way satellite time and frequency transfer, or via optical fibres. These all need to be processed to compensate for the delay due, for example, to the ionosphere, the gravitational field, or the movement of satellites.
----

As an aside, I find the most interesting "fudge factor" to be the correction for "the gravitational field", wherein a "correction factor" is applied to the "time" from each of the world's atomic clocks to account for "gravitational time dilation".  None of the world's atomic clocks actually keep the same "time".

Nevertheless, rather than discussing the complicated *source* of UTC, instead, the question I am raising here has to do with how we *communicate* UTC, and in particular, how we communicate the UTC using the POSIX compatible command `date -u`.  And for that, it might be most useful to reference ISO 8601, "Date and time format", https://www.iso.org/iso-8601-date-and-time-format.html

And for those people prone to "TL;DR", summarizing:
----
For example, September 27, 2022 at 6 p.m. is represented as 2022-09-27 18:00:00.000.
----

Translating, ISO 8601, the International Standard for Date and Time Format uses a 24 hour clock time format, not a 12 hour format.

Furthermore, it must be noted that UTC itself is *not* dependent upon any "time zone", though ISO 8601 does provides display formats which *include* an offset relative to UTC to display local time in different time zones.

Then perhaps I am contradicting my original argument, that "UTC" should be displayed in 24 hour format because "UTC is in England", where the C locale uses a 24 hour time format and because the USA NOAA compares UTC to GMT, such that your point is taken.  I make this appeal to ISO 8601 in its place.

For anyone inclined to accept my appeal to ISO 8601, the current display format returned by `date -u`, especially within the USA, is wrong, and that is a bug that needs to be fixed.

Are you inclined to accept the time format of ISO 8601 for the display of UTC - or no?

As an aside, for anyone inclined to read further, I found this bit of trivia interesting:
https://en.wikipedia.org/wiki/Greenwich_Mean_Time#Ambiguity_in_the_definition_of_GMT

Which to understand, note https://en.wikipedia.org/wiki/Transit_instrument and that astronomers would not see the sun at midnight - thus the significance of Latin "ante meridiem" and "post meridiem" - while European astronomers would record 24 distinct hours in a "day", as was Roman tradition, though Japanese astronomers used a complete day of 12 hours up to 1873, and Hindu astronomers a complete day of 30 muhurtas, up to British colonial rule.  However, perhaps given the  inconvenience to merchants of having the "day of the week" change in the "middle" of the business day, the International Meridian conference of 1884 adopted a resolution that "the astronomical and nautical days will be arranged everywhere to begin at mean midnight."  Related: http://www.royalobservatorygreenwich.org/articles.php?article=1077 and http://www.royalobservatorygreenwich.org/articles.php?article=1087


James

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.