Subject: Re: bug#79261: coreutils 9.7 "date -u" - timezone offset is in the wrong direction

From: Martin D Kealey <[email-masked]>
Date: Sat, 30 Aug 2025 01:51:02 +1000

On Tue, 26 Aug 2025, 07:15 James Feeney, <[email-masked]> 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