Re: [saag] [art] Date formats: RFC3339 vs. RFC 5322

[Phillip Hallam-Baker <[e-mail]>]

On Thu, Apr 15, 2021 at 6:30 AM Stian Soiland-Reyes <
[e-mail]> wrote:

> On 2021-04-14 Phillip Hallam-Baker <[e-mail]> wrote:
>
> > Unfortunately, the method of platform handling of UTC means that all
> date time
> > values recorded in electronic documents are inherently ambiguous, a
> state
> > of affairs that will persist until the cretinous notion of leap seconds
> is
> > done away with.
>
> Leap seconds won't go away unless you change the duration of a second or
> planet's rotation..
>

Untrue, there is no reason that time needs to bear any relation to the
rotation of Earth, Saturn or any other planet. The time of noon changes by
15 minutes over the course of a year in Northern Europe.

Why not move the longitude lines to compensate instead?


> I don’t think UTC or TAI makes a big difference in this draft on
> security!  But it can make a big difference if assuming 00:00:00 UTC as it
> can become 23:59:59 (or indeed 23:59:60) on the previous day.
>

That is only one means of adjusting for leap seconds. Most infrastructure
has moved to smearing the second in over a longer time to avoid
instability. The people who maintain the parts of various platforms dealing
with time know all about leap seconds. But none of the ones I use generate
23:59:60 because the risk of breaking things with an untested, untestable
code path is simply too great to be worth doing.

And that is the root of the problem, there is no consistency across
platforms and applications in applying leap seconds. It is impossible to
know whether you are dealing with adjusted or unadjusted time.