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

Previous Next

To reply to this bug, email your comments to 79261 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: James Feeney <james <at> nurealm.net>
To: bug-coreutils <at> gnu.org
Subject: coreutils 9.7 "date -u" - timezone offset is in the wrong direction
Date: Sun, 17 Aug 2025 10:02:40 -0600

Arch Linux
coreutils 9.7-1

$ timedatectl;date;date -u
               Local time: Sun 2025-08-17 09:50:24 MDT
           Universal time: Sun 2025-08-17 15:50:24 UTC
                 RTC time: Sun 2025-08-17 15:50:24
                Time zone: US/Mountain (MDT, -0600)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
Sun Aug 17 09:50:24 AM MDT 2025
Sun Aug 17 03:50:24 PM UTC 2025

`timedatectl` is correct.
`date` is correct.
`date -u` is off by 2x the timezone offset, showing UTC as 6 hours earlier, which is wrong, instead of 6 hours later, which is correct.


Please fix.

James

Message #8 received at 79261 <at> debbugs.gnu.org (full text, mbox):

From: "Glenn Golden" <gdg <at> zplane.com>
To: james <at> nurealm.net, 79261 <at> debbugs.gnu.org
Subject: Re: bug#79261: coreutils 9.7 "date -u" - timezone offset is in the
 wrong direction
Date: Sun, 17 Aug 2025 20:20:40 -0600

On Sun, Aug 17, 2025, at 10:02, James Feeney via GNU coreutils Bug Reports wrote:
> Arch Linux
> coreutils 9.7-1
>
> $ timedatectl;date;date -u
>                Local time: Sun 2025-08-17 09:50:24 MDT
>            Universal time: Sun 2025-08-17 15:50:24 UTC
>                  RTC time: Sun 2025-08-17 15:50:24
>                 Time zone: US/Mountain (MDT, -0600)
> System clock synchronized: yes
>               NTP service: active
>           RTC in local TZ: no
> Sun Aug 17 09:50:24 AM MDT 2025
> Sun Aug 17 03:50:24 PM UTC 2025
>
> `timedatectl` is correct.
> `date` is correct.
> `date -u` is off by 2x the timezone offset, showing UTC as 6 hours 
> earlier, which is wrong, instead of 6 hours later, which is correct.
>

UTC = 09:50:24 MDT + 6hr = 15:50:24 = 03:50:24 PM, which is what date -u shows.

Message #11 received at 79261 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: james <at> nurealm.net, 79261 <at> debbugs.gnu.org
Subject: Re: bug#79261: coreutils 9.7 "date -u" - timezone offset is in the
 wrong direction
Date: Mon, 18 Aug 2025 10:26:05 +0100

tag 79261 notabug
close 79261
stop

On 17/08/2025 17:02, James Feeney via GNU coreutils Bug Reports wrote:
> Arch Linux
> coreutils 9.7-1
> 
> $ timedatectl;date;date -u
>                 Local time: Sun 2025-08-17 09:50:24 MDT
>             Universal time: Sun 2025-08-17 15:50:24 UTC
>                   RTC time: Sun 2025-08-17 15:50:24
>                  Time zone: US/Mountain (MDT, -0600)
> System clock synchronized: yes
>                NTP service: active
>            RTC in local TZ: no
> Sun Aug 17 09:50:24 AM MDT 2025
> Sun Aug 17 03:50:24 PM UTC 2025
> 
> `timedatectl` is correct.
> `date` is correct.
> `date -u` is off by 2x the timezone offset, showing UTC as 6 hours earlier, which is wrong, instead of 6 hours later, which is correct.

I think you missed the "PM" in the output above.

cheers,
Pádraig

Message #18 received at 79261 <at> debbugs.gnu.org (full text, mbox):

From: James Feeney <james <at> nurealm.net>
To: Pádraig Brady <P <at> draigBrady.com>, 79261 <at> debbugs.gnu.org
Subject: Re: bug#79261: coreutils 9.7 "date -u" - timezone offset is in the
 wrong direction
Date: Tue, 19 Aug 2025 09:13:05 -0600

Hey Pádraig

On Mon, 2025-08-18 at 10:26 +0100, Pádraig Brady wrote:
> tag 79261 notabug
> close 79261
> stop
> 
> ...
> 
> I think you missed the "PM" in the output above.
> 
> cheers,
> Pádraig


Yes, that's it, along with the coincidence that MDT relative to UTC is exactly 12 hours.  Thanks for pointing-out the glaringly obvious in retrospect.

Reviewing the `man 1 date` page, and after some trial and error:
----
$ date -uR
Tue, 19 Aug 2025 14:35:50 +0000
----

I did also resort to "time format 24 hours on shell with date command":
https://askubuntu.com/questions/1238397/ubuntu-server-20-04-time-format-24-hours-on-shell-with-date-command

which comments that:
----
24-hour clock in en_US locale was a bug in glibc locale definition and has been corrected in this commit. So, the change was intentional. – 
Mateusz
Commented May 14, 2020 at 19:29
----

referencing:
https://sourceware.org/git/?p=glibc.git;a=commit;h=7395f3a0efad9fc51bb54fa383ef6524702e0c49

----
en_US: define date_fmt (bug 24046)
author	Aurelien Jarno <aurelien <at> aurel32.net>	
	Sun, 30 Dec 2018 17:29:53 -0600 (00:29 +0100)

The en_US locale use a 12h am/pm format in both d_fmt and d_t_fmt, which is correct, but does not define date_fmt. This causes the default value to be used, which is in 24h format.
----

Apparently, I do not use the date command often enough to have appreciated this "misfeature" applied to the `date` command six years ago - of course, coupled with not being able to properly read what is printed on the screen.

There is another comment, which expresses well my opinion on the matter:
----
I don't know why the 24-hours format has to have anything to do with "Great Britain" or "United States". –
Yan King Yin
Commented Dec 19, 2022 at 7:16
----

Still, thanks for the hand-holding.

James

Message #21 received at 79261 <at> debbugs.gnu.org (full text, mbox):

From: "Glenn Golden" <gdg <at> zplane.com>
To: james <at> nurealm.net, 79261 <at> debbugs.gnu.org
Subject: Re: bug#79261: coreutils 9.7 "date -u" - timezone offset is in the
 wrong direction
Date: Tue, 19 Aug 2025 12:55:10 -0600

On Tue, Aug 19, 2025, at 09:13, James Feeney via GNU coreutils Bug Reports wrote:
>
> Yes, that's it, along with the coincidence that MDT relative to UTC is 
> exactly 12 hours.
>

That coincidence is true only in base 4. :)

Message #24 received at submit <at> debbugs.gnu.org (full text, mbox):

From: James Feeney <james <at> nurealm.net>
To: Pádraig Brady <P <at> draigBrady.com>, 
 79261 <at> debbugs.gnu.org, bug-coreutils <bug-coreutils <at> gnu.org>
Cc: Aurelien Jarno <aurelien <at> aurel32.net>
Subject: Re: bug#79261: coreutils 9.7 "date -u" - timezone offset is in the
 wrong direction
Date: Sun, 24 Aug 2025 15:33:41 -0600

By the way, aside from properly reading what is actually on the screen, or not, it must also be noted that "UTC" is in *Great Britain*, where the local "locale" is "en-GB", and the standard time format in Great Britain is 24 hour, not 12 hour.  Thereby, it seems to me that reporting UTC in 12 hour format is just plain wrong.

Some people will argue that UTC is a "time" and not a "time zone".  Then also, it is not entirely sensible say both that "the current UTC time must have a display format in this such time zone", and then to say that "UTC is not a time zone".  Consider, when reading from https://www.wpc.ncep.noaa.gov/html/FAQs_1.html in the United States:
----
When you see 12 UTC or 1200 UTC or 12Z (all are the same and depend on forecaster preference), it refers to noon at Greenwich.  00 UTC or 00Z is midnight Greenwich time.
----
"Greenwich time" is the time in Greenwich, not the time somewhere else in the world.  Since 1968 December, the audio announcements from the WWV broadcasts from Fort Collins Colorado always say "Coordinated Universal Time", in 24 hour format, and *not* "Mountain Daylight Time", in 12 hour format.

We note that `man 1 date` explicitly says that `date -u` will display "UTC" time:
----
       -u, --utc, --universal
              print or set Coordinated Universal Time (UTC)
----
It never occurred to me that UTC could ever be reported in a 12 hour format.  I still think of this as a bug, or at least a "misfeature", where conversely, someone had reported *not* using the local "locale" to display the time in the `date` command as a bug.  While this might be thought of as a "cultural" difference in interpretation, I believe that "UTC" itself should be the "UTC" of Great Britain, "+0000", never some UTC in MDT, despite the US NIST-F4 time standard being in Boulder Colorado.

Actually, it may be proper to display the result of `date` in the local "locale" format generally, but then also, to display UTC from `date -u` as properly in "Greenwich time", in England, with the en-GB locale.  When "UTC" from `date -u` is displayed in a different format, in every different country and in every different time zone, there is much less that is "universal" about "UTC", and "UTC" is much less of a constant that you can trust.

I would like to know other people's thoughts on the question of whether "UTC" has the time format of Great Britain, or the time format of some other location.

Perhaps also read comments from the prior change to the display format here:
https://patchwork.ozlabs.org/project/glibc/patch/20181230235437.20485-1-aurelien <at> aurel32.net/


James

Message #30 received at 79261 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: james <at> nurealm.net
Cc: 79261 <at> debbugs.gnu.org, Aurelien Jarno <aurelien <at> aurel32.net>
Subject: Re: bug#79261: coreutils 9.7 "date -u" - timezone offset is in the
 wrong direction
Date: Sun, 24 Aug 2025 16:17:12 -0700

On 2025-08-24 14:33, James Feeney via GNU coreutils Bug Reports wrote:
> reporting UTC in 12 hour format is just plain wrong.

No it's fine, actually. UTC is a world-wide standard; it's not local to 
Greenwich. Many people prefer 12-hour format, and there's nothing wrong 
with displaying UTC that way.

And even if I agreed with you, longstanding practice is to for "date -u" 
to respect the current locale, and POSIX requires this behavior. So 
there are good reasons for keeping the behavior the way it is.

To get the behavior you prefer, you can run "LC_ALL=C date -u", "date -u 
+'%Y-%m-%d %H:%M:%S'", or similar commands.

Message #33 received at submit <at> debbugs.gnu.org (full text, mbox):

From: James Feeney <james <at> nurealm.net>
To: Martin D Kealey <martin <at> kurahaupo.gen.nz>, 79261 <at> debbugs.gnu.org, 
 bug-coreutils <bug-coreutils <at> gnu.org>
Subject: Re: 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

Message #39 received at 79261 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: james <at> nurealm.net
Cc: 79261 <at> debbugs.gnu.org, martin <at> kurahaupo.gen.nz
Subject: Re: bug#79261: coreutils 9.7 "date -u" - timezone offset is in the
 wrong direction
Date: Mon, 25 Aug 2025 15:20:56 -0700

On 2025-08-25 14:15, James Feeney via GNU coreutils Bug Reports wrote:
> 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?

We should not change the behavior of plain 'date -u' based on any 
arguments presented so far in this thread. The current behavior is 
longstanding, documented, required by POSIX, and plenty of people 
undoubtedly depend on it.

To get 24-hour notation for UTC with 'date', you can run this:

  date -u +'%Y-%m-%d %H:%M:%S'

or this:

  LC_ALL=C date -u

Either of these work with any POSIX-conforming 'date'. GNU 'date' has 
other options (--iso-8601, --rfc-3339) that may be more convenient but 
are less portable. This sort of thing should be enough to satisfy the 
need here.

Message #42 received at 79261 <at> debbugs.gnu.org (full text, mbox):

From: James Feeney <james <at> nurealm.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 79261 <at> debbugs.gnu.org, bug-coreutils <bug-coreutils <at> gnu.org>,
 martin <at> kurahaupo.gen.nz
Subject: Re: bug#79261: coreutils 9.7 "date -u" - timezone offset is in the
 wrong direction
Date: Tue, 26 Aug 2025 09:43:20 -0600

On Mon, 2025-08-25 at 15:20 -0700, Paul Eggert wrote:
> > 
> > Are you inclined to accept the time format of ISO 8601 for the display of UTC - or no?
> 
> We should not change the behavior of plain 'date -u' based on any 
> arguments presented so far in this thread. The current behavior is 
> longstanding, documented, required by POSIX, and plenty of people 
> undoubtedly depend on it.
> 

Your definition of "longstanding" seems a bit disingenuous, since this change, from the default POSIX `date -u` 24 hour format to the 12 hour format, was made in 2020, 5 years ago, while the GNU shellutils package was announced in 1991, 21 years prior to this change to the time format.  And then, to say "undoubtedly depend" is to presume a conclusion, with no evidence whatsoever.  As was reiterated by Martin, and admitted, UTC *itself* has nothing to do with time zones.

James

Message #48 received at 79261 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: james <at> nurealm.net
Cc: 79261 <at> debbugs.gnu.org, bug-coreutils <bug-coreutils <at> gnu.org>,
 martin <at> kurahaupo.gen.nz
Subject: Re: bug#79261: coreutils 9.7 "date -u" - timezone offset is in the
 wrong direction
Date: Tue, 26 Aug 2025 12:54:36 -0700

On 8/26/25 08:43, James Feeney wrote:
> Your definition of "longstanding" seems a bit disingenuous, since this change, from the default POSIX `date -u` 24 hour format to the 12 hour format, was made in 2020

? No it wasn't. I just now ran 'date -u' from the coreutils 5.93 (2005) 
shipped with Solaris 10, and it uses 12 hour format when run in a locale 
specifying that format. And I'm sure this behavior predates 2005.

Message #54 received at 79261 <at> debbugs.gnu.org (full text, mbox):

From: Martin D Kealey <martin <at> kurahaupo.gen.nz>
To: james <at> nurealm.net
Cc: 79261 <at> debbugs.gnu.org
Subject: Re: bug#79261: coreutils 9.7 "date -u" - timezone offset is in the
 wrong direction
Date: Sat, 30 Aug 2025 01:51:02 +1000

[Message part 1 (text/plain, inline)]

On Tue, 26 Aug 2025, 07:15 James Feeney, <james <at> nurealm.net> wrote:

> Hey Martin
>
> On Mon, 2025-08-25 at 20:10 +1000, Martin D Kealey wrote:
> > TL;DR locale and timezone are independent; neither implies the other.
>
> 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"?
>

My personal preference? @%s%N
My second preference? %F,%T%N

That said, I don't think TZ=UTC (or equivalently date -u) should control
the time format; that's what LC_TIME is for.

Perhaps we would ask for 'date' to have option '-x' to be a synonym for
'--iso-full', then we can type 'date -zx'. ('x' because it's adjacent to
'z', to be quick to type.)

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

There have been several proposals to abandon this approach, or to increase
the difference limit by a factor of at least 60, which would mean
adjustments could be published decades in advance and the next in will be
centuries away.

The main supposed beneficiaries of leap seconds are astronomers, but in
practice this is a chimera: (1) astronomy requires sub-second resolution to
identify & track distant objects so allowing even 0.9 seconds drift is too
much, and (2) reference time is translated to sidereal time, which itself
drifts and jitters due to Earth's axial tilt precession.

Almost nobody else benefits from having such a small permitted difference
because it's utterly swamped by the seasonal drift of solar noon by several
minutes, due to Earth's eccentric orbit.

Meanwhile leap seconds are actively problematic to precise timekeeping,
especially GPS & financial transactions.

-Martin

[Message part 2 (text/html, inline)]

Previous Next

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