Subject: [art] Fwd: Confirm submission of I-D draft-touch-time

From: Joe Touch <[email-masked]>
Date: Mon, 22 Jan 2018 17:45:06 -0800

HI, all,

I’ve updated draft-touch-time.

Note that there may be pending edits not yet incorporated - I’ll post more on that shortly.

Joe

> Begin forwarded message:
> 
> From: IETF I-D Submission Tool <[email-masked]>
> Subject: Confirm submission of I-D draft-touch-time
> Date: January 19, 2018 at 5:47:54 PM PST
> To: "Joseph Touch" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
> 
> 
> Hi,
> 
> The IETF datatracker draft submission service has received your draft
> draft-touch-time-03, and requires a
> confirmation step in order to be able to complete the posting of
> the draft.
> Please follow this link to the page where you can confirm the posting:
> 
> https://datatracker.ietf.org/submit/status/92363/confirm/6323bcc3041c402c77999b95e5f00510/
> 
> 
> Best regards,
> 
> 	The IETF Secretariat
> 	through the draft submission service
> 
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 22 Jan 2018 17:47:36 -0800

> On Jan 22, 2018, at 5:45 PM, Joe Touch <[email-masked]> wrote:
> 
> HI, all,
> 

FYI - here’s the correct link and context:

A new version of I-D, draft-touch-time-03.txt
has been successfully submitted by Joe Touch and posted to the
IETF repository.

Name:		draft-touch-time
Revision:	03
Title:		Resolving Multiple Time Scales in the Internet
Document date:	2018-01-19
Group:		Individual Submission
Pages:		19
URL:            https://www.ietf.org/internet-drafts/draft-touch-time-03.txt <https://www.ietf.org/internet-drafts/draft-touch-time-03.txt>
Status:         https://datatracker.ietf.org/doc/draft-touch-time/ <https://datatracker.ietf.org/doc/draft-touch-time/>
Htmlized:       https://tools.ietf.org/html/draft-touch-time-03 <https://tools.ietf.org/html/draft-touch-time-03>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-touch-time-03 <https://datatracker.ietf.org/doc/html/draft-touch-time-03>
Diff:           https://www.ietf.org/rfcdiff?url2=draft-touch-time-03 <https://www.ietf.org/rfcdiff?url2=draft-touch-time-03>

Abstract:
  Internet systems use a variety of time scales, which can complicate
  time comparisons and calculations. This document explains these
  various ways of indicating time and explains how they can be used
  together safely. This document is intended as a companion to
  Internet time as discussed in RFC 3339.

---

From: Steve Allen <[email-masked]>
Date: Sat, 27 Jan 2018 11:08:06 -0800

> Note that there may be pending edits not yet incorporated - I’ll post more on that shortly.

I offer the following toward improvements in the document.

> 1. Introduction

This section has a numbered list of recommendations.
List point 3 is about UTC, and reasons to use UTC are broader than
given in the current text.  They include the following:

UTC is the time scale that the ITU-R recommends for use in radio broadcast time signals
ITU-R TF.460

UTC is the time scale that the ITU-R recommends for use in communications of time and date
ITU-R Radio Regulations 2.6

UTC is the time scale that the ITU-T recommends for use in communications of time and date
7th Plenary Assembly of the CCITT in 1980-11

UTC is the time scale that the CGPM strongly endorsed as the basis for civil time
Resolution 5 of the 15th meeting of the CGPM in 1975-05/06
http://www.bipm.org/en/CGPM/db/15/5/

UTC is the time scale that members of the BIPM routinely intercompare to compute TAI
as seen in BIPM Circular T
https://www.bipm.org/en/bipm-services/timescales/time-ftp/Circular-T.html
and its explanatory supplement
ftp://ftp2.bipm.org/pub/tai/publication/notes/explanatory_supplement_v0.1.pdf

UTC is the legal or official time scale in many countries whose
national metrology agencies are members of the BIPM and which provide
the radio broadcast time signals as that legal time.

> Section 3.  Terminology

This section defines terms, and those terms are used differently in
the older language of some of the citations.

In older documents the term "epoch" meant what we now generally call a
"date".  In particular "epoch" was any instant which could be
unambiguously recognized and generally agreed upon, thus an epoch
could be any "date and time" within a calendar based on the rotation
of the earth which all parties had the ability to observe and measure.

"Solar day"
The final sentence should read
"A given apparent solar day can vary by as much as 30 seconds vs. the mean."
Except that really that should be omitted altogether because ...

The notion of apparent solar day is irrelevant to this document.
There is no service which provides values of apparent solar time.
Other than observers looking at the shadow of a stick in the ground
there are no consumers of values of apparent solar time.
Starting in 1833 the UK Nautical Almanac abandoned the tabulation of
apparent solar time in favor of mean solar time because by then the
Admiralty allowed that the navigator of any ship had a chronometer.
Only the mean solar day is relevant to this document, and all
discussionsof variation in the apparent solar day should be omitted.

"Tropical Year"
Replace the current text with the following:

Tropical Year: a unit of time defined by the interval of one
revolution of the earth around the sun in its mean orbit as measured
with respect to the mean equinox.

"Leap seconds"
replace "based on solar days" with "based on mean solar days
as measured using UT1".

> Section 4.2 Time Scales

This section includes a definition of TAI and reference.
That definition is currently being reworked to harmonize
with the IAU definition of Terrestrial Time (TT).
In the redefinition there will be no reference to a geoid

CCTF has produced draft of new definition of TAI for BIPM
http://www.iaufs.org/CCTF%20Recommendation-DRAFT.pdf
this has been approved by 2017 Oct CIPM for inclusion into the
resolutions for the draft resolutions of the 2018 Nov CGPM.
https://www.bipm.org/cc/PARTNERS/Allowed/2017_October/Plans-for-the-26th-CGPM-M-MILTON.pdf

TAI is irrelevant to this document because no service can provide it
to an operational system.  TAI is only available after the fact
in the publication of BIH Circular T.

See the current BIPM circular T
ftp://ftp2.bipm.org/pub/tai//Circular-T/cirthtm/cirt.360.html
Note that the time labs intercompare their values of UTC(k).
Note that no value of TAI is given other than as an offset from UTC.

Only versions of UTC(k) exist in real time.
UTC does not exist until Circular T is published the next month,
and that will also define TAI as an offset from UTC.

A system can only use TAI if it had realtime access to a
value of UTC(k) and then after the publication of Circular T
applies the corrections to the recorded values of UTC(k).

This section also contains a definition of Universal Time
that deserves better treatment.

UT (Universal Time) is a time scale based on measuring the rotation of
the earth.  UT is a subdivision of the Universal Day which was agreed
as the basis for civil time at International Meridian Conference in
1884.
ref
https://en.wikipedia.org/wiki/International_Meridian_Conference

Since 1928 UT has been synonymous with Greenwich Mean Time.
ref
text from IAU Commission 4 at the 1928 GA in
https://www.iau.org/static/resolutions/IAU1928_French.pdf

UT has several variants which have during various intervals been the
basis for civil time.
ref
Bulletin Horaire, series 4, numbers 3 and 4 in 1955
https://www.ucolick.org/~sla/leapsecs/BH1955.html

Originally UT was a subdivision of the mean solar day measured
using a specific meridian on earth (Greenwich) and a specific
celestial reference point (the mean equinox).
Most common in recent usage is UT1 which since 2003 measures earth
rotation using fully relativistic transformations, models for plate
tectonics, and motions of fluids in core, oceans, and atmosphere.
ref
IAU 2000 resolution B1.8
https://www.iau.org/static/resolutions/IAU2000_French.pdf

Proceeding onward to the other time scales ...

Ephemeris Time is only tangentially relevant to this document.
No source provides Ephemeris Time.  No consumers use Ephemeris Time.
The current variation of Ephemeris Time most relevant to this
document is Terrestrial Time (TT) which is the ideal time scale
that TAI strives to realize.

GPS is not defined as tracking TAI.
GPS is defined by IS-GPS-200H plus subsequent IRNs
https://www.gps.gov/technical/icwg/
The term TAI and the words International Atomic Time exist nowhere in
the defining documents for GPS.

In particular see IS-GPS-200H paragraph
3.3.4 GPS Time and SV Z-Count.
where the first line is
"GPS time is established by the Control Segment and is referenced to
Coordinated Universal Time (UTC) as maintained by the U.S. Naval
Observatory (UTC (USNO))"

So GPS time is defined as UTC(USNO) + (numleaps - 9) seconds.

Why is PTP aka IEEE 1588-2002 aka ITU-T Recommendation G.8265.1
not mentioned in this document?

%%%%%%%%%%%%%

> 4.3 Comparison of Properties

Uniform should end its definition more like
"all intervals of the same size represent the same amount of time in
the specific reference frame of that time scale."

Missing from this list of properties is:
Availability
more specifically, availability in real time.

TAI is not available in real time, and neither is UTC.

UTC(k) can be available in real time.
For example, a good GPS receiver which follows IS-GPS-200H by applying
the SV clock correction polynomial, the GPS time polynomial, the
general relativity, and the ionosperic correction can give a good
real time estimate of UTC(USNO).
For details of that the references are in IS-GPS-200H
20.3.3.5.2.4 Coordinated Universal Time (UTC).
20.3.3.5.2.3 Almanac Time Parameters.

A financial exchange whose regulators require that transactions be
accurately timestamped can contract to lease a fiber to a national
metrology institute to get access to that version of UTC(k).

A rather old publication may yet be a good reference here.
HP Application Note 1289
http://www.allanstime.com/Publications/DWA/Science_Timekeeping/TheScienceOfTimekeeping.pdf
See Table C1 for the technologies and costs and precision tradeoffs.
Also note that nowhere does it indicate that TAI is available.

> 5 Systems that report time

This section must reference BIPM Circular T and its explanatory
supplement.

This section should distinguish between reports of time
(as in Circular T for TAI, and IERS publications for UT1)
and systems which provide time in real time.

> 6.1.1 Continuous and uniform

As noted above, strike the equation relating GPS and TAI.

Again, the current length of day in SI seconds of TT (or TAI) should
reference IERS.

> 6.1.3 Not uniform

Strike the sentence about Solar days varying by as much as 50 seconds
because that should read "Apparent Solar Days" and because there are
no sources nor consumers of apparent solar time.

Strike the entire sentence about variations in the earth orbit over
time.  Those variations are small by comparison to earth rotation, but
more importantly, there are no sources nor consumers of earth orbit
time and this document gains nothing by veering that far off into
celestial mechanics.

Strike the entire sentence about GPS using its own clocks rather than
TAI.  TAI does not exist in real time, so it is not possible for an
operational system to refer to it.

--
Steve Allen                    <[email-masked]>              WGS-84 (GPS)
UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
1156 High Street               Voice: +1 831 459 3046         Lng -122.06015
Santa Cruz, CA 95064           http://www.ucolick.org/~sla/   Hgt +250 m

---

From: "Manger, James" <[email-masked]>
Date: Mon, 29 Jan 2018 04:49:59 +0000

Comments on draft-touch-time-03 (https://tools.ietf.org/html/draft-touch-time-03):

Given that the main argument against a time scale that smears out leap seconds is the lack of a current standard, the best contribution this document could make is to document as an RFC the "24-hour linear smear from noon to noon UTC" now used by Google (https://developers.google.com/time/smear), Amazon etc. That means interval measurements are not complicated at all unless you need precision better that 11.6ppm (0.00116%; 1 second in 24 hours); and if you do need that precision it is still possible as the smearing is simple & deterministic once you know when leap seconds occur.

--
James Manger

---

From: Joe Touch <[email-masked]>
Date: Sun, 28 Jan 2018 22:24:27 -0800

Hi, James,

On 1/28/2018 8:49 PM, Manger, James wrote:
> Given that the main argument against a time scale that smears out leap seconds is the lack of a current standard, 
Please recheck the draft. That is not the main argument; there are many
other reasons, not the least of which is the inability of a method to
convert reliably from smeared time to those used in nearly every other
context.

> the best contribution this document could make is to document as an RFC the "24-hour linear smear from noon to noon UTC" now used by Google (https://developers.google.com/time/smear), Amazon etc. That means interval measurements are not complicated at all unless you need precision better that 11.6ppm (0.00116%; 1 second in 24 hours); and if you do need that precision it is still possible as the smearing is simple & deterministic once you know when leap seconds occur.
11.6 ppm is 11.6 milliseconds. There are many systems that need
precision far beyond that, down at 1ms or even lower.

Joe

---

From: "Manger, James" <[email-masked]>
Date: Tue, 30 Jan 2018 07:06:07 +0000

> convert reliably from smeared time to those used in nearly every other

"24-hour linear smear from noon to noon UTC" allows precise conversion to UTC.
If you know your time is smeared, but not which variety of smear, then you cannot precisely convert -- but that was why 1 smear RFC would be great.
For reliability when you aren't certain how systems handle leap seconds (UTC or smear or ignore or ...), smeared time will almost always be better. 99.9% of the time (days without a leap second) intervals are precise, in the remaining corner cases a 24-hour linear smear ensures an error in *any* interval duration (whether 1ns or 1hr) is always less than 0.00116%, while other timescales might by precise or might give a +/-1s error (which might be a 0.001% error or a 10% error or a 10000% error depending on the duration of the interval!).

>precision far beyond that, down at 1ms or even lower.

11.6ppm is NOT 11.6ms, unless your interval is 1000s. Google's smear gives at least 1ms precision for any interval below 86.4s in duration.

--
James Manger

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 Jan 2018 06:48:22 -0800

> On Jan 29, 2018, at 11:06 PM, Manger, James <[email-masked]> wrote:
> 

Only if you know exactly on what day the smear occurred. That means you need to know the same kind of online information as UTC.

> If you know your time is smeared, but not which variety of smear, then you cannot precisely convert -- but that was why 1 smear RFC would be great.

It is the addition of smear that adds that confusion. We already have a single, common time frame that is in widespread use, and using that would avoid all of this.

> For reliability when you aren't certain how systems handle leap seconds (UTC or smear or ignore or ...), smeared time will almost always be better. 

A system that doesn’t support UTC is admitting it doesn’t care about time to with a second anyway.  

> 99.9% of the time (days without a leap second) intervals are precise, in the remaining corner cases a 24-hour linear smear ensures an error in *any* interval duration (whether 1ns or 1hr) is always less than 0.00116%, while other timescales might by precise or might give a +/-1s error (which might be a 0.001% error or a 10% error or a 10000% error depending on the duration of the interval!).\

Smearing means you can no longer compare time intervals directly without that error. The percentages you’re citing are simply not acceptable - they could mean the difference of events happening in different days or even years, given that the smear would happen over a day within different time zones in different ways. UTC is the only way to ensure that this isn’t true - all UTC times are directly comparable and can be directly sequenced.

So smearing adds a mess of complication - all just to give people the incorrect impression that the time didn’t jump. However, time DID jump - because government time is nearly universally based on UTC. 

> 11.6ppm is NOT 11.6ms, unless your interval is 1000s. Google's smear gives at least 1ms precision for any interval below 86.4s in duration.

1ms of error in a timestamp is more than enough to undermine financial and government systems. 

Joe

---

From: "Manger, James" <[email-masked]>
Date: Wed, 31 Jan 2018 06:38:01 +0000

When you know the dates of leap seconds, you can precisely convert between UTC and "24-hour linear smear from noon to noon UTC". So there can't be any errors or ambiguity or confusion inherent to either. They are isomorphic!

The difference is in what glitches/wrinkles/warts are likely to occur when the time scale meets a mass of apps/APIs/systems/protocols/data-structures/etc that can't or don't want to handle special cases such as seconds=60 (instead of 0-59).

> using [UTC] would avoid all of this [confusion]

That is clearly wrong given systems that do wonky hacks like reporting the same time value during a leap second, incremented by 1 ns on each read.

> all UTC times are directly comparable and can be directly sequenced.

So are all smeared times. "24-hour linear smear from noon to noon UTC" is between noon UTC so everywhere (regardless of timezone) has the same smear at any instant.

--
James Manger

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Wednesday, 31 January 2018 1:48 AM
To: Manger, James <[email-masked]>
Cc: Applications and Real-Time Area Discussion <[email-masked]>
Subject: Re: [art] Confirm submission of I-D draft-touch-time

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 Jan 2018 22:48:54 -0800

> On Jan 30, 2018, at 10:38 PM, Manger, James <[email-masked]> wrote:
> 

Except that UTC can be computed in seconds exactly; smear is susceptible to the limits of the precision of your floating point calculations.

> The difference is in what glitches/wrinkles/warts are likely to occur when the time scale meets a mass of apps/APIs/systems/protocols/data-structures/etc that can't or don't want to handle special…

Apps typically don’t handle this; OSes (already) do this conversion.

Additionally, apps that don’t understand that some minutes have 60 seconds are incorrect and cannot operate with the time the rest of the world has already adopted.

> That is clearly wrong given systems that do wonky hacks like reporting the same time value during a leap second, incremented by 1 ns on each read.

Apps that incorrectly use the OS interfaces to time will continue to do so; adding another time frame invites additional errors rather than preventing them.

> So are all smeared times. "24-hour linear smear from noon to noon UTC" is between noon UTC so everywhere (regardless of timezone) has the same smear at any instant.

Except for the resolution of the floating point calculation that could affect the way in which the smear is continuously applied to increasingly more precise time intervals.

The fundamental issue is that smear doesn’t relieve apps from needing to have updated info on leap seconds. It only serves to make interoperation with the time already adopted as universal worldwide more difficult. If you already need to know about leap seconds, it’s far simpler to just use them directly and match time to UTC.

By avoiding smear, we ensure that “10 seconds” means the same thing at all times, everywhere. Smeared time can be whatever it wants, but on days when it’s smeared, it shouldn’t ever use the term ‘second’.

Joe

> _______________________________________________
> art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/art

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 31 Jan 2018 08:22:24 +0100

On Jan 31, 2018, at 07:38, Manger, James <[email-masked]> wrote:
> 
> 24-hour linear smear from noon to noon UTC

I propose the name “Smeared Leapsecond over twentyfour hours" — SLOTH.

More seriously, I agree with your quest for a standard smear.

As Joe correctly says, UTC doesn’t have a problem that needs to be solved here.

But this is not about UTC, it is about the Posix timescale, which is a corruption of UTC that is not maintaining the monotonous property.  SLOTH is a much better time scale for most systems that have to contend with the Posix time scale now.

(I’m interested in this discussion because of CBOR tags 1 [RFC7049] and 1001 [draft-bormann-cbor-time-tag].)

Grüße, Carsten

PS.: Why couldn't they make it 100000 seconds….

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 31 Jan 2018 18:42:58 +1100

> On 31 Jan 2018, at 6:22 pm, Carsten Bormann <[email-masked]> wrote:
> 

That's going to stick...

> More seriously, I agree with your quest for a standard smear.

+1. 

--
Mark Nottingham   https://www.mnot.net/

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 Jan 2018 23:45:56 -0800

> On Jan 30, 2018, at 11:22 PM, Carsten Bormann <[email-masked]> wrote:
> 
>  SLOTH is a much better time scale for most systems that have to contend with the Posix time scale now.

Can you explain why this is better than using UTC?

My concern is that is is not only unnecessarily different, but it contaminated the notion of time intervals too - a second on a smear day isn’t a second on any other. 

Joe

---

From: Philip Homburg <[email-masked]>
Date: Wed, 31 Jan 2018 10:49:46 +0100

> More seriously, I agree with your quest for a standard smear.

I'd like to propose a rule that if a system returns a timestamp that is
subject to smear, it is tagged as such.

So in the context of NTP, there needs to be a flag of some kind that signals
that the timestamps in the packet are subject to smear. In the case of an API,
ideally the system returns that the time is smeared. Or the application
requests that explicitly.

For example in the context of the POSIX clock_gettime call, add a
CLOCK_REALTIME_SMEARED clock.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 31 Jan 2018 16:38:25 +0100

> Can you explain why this is better than using UTC?

It’s not — it’s just not on the table with most applications that are running on the Posix time scale.

> My concern is that is is not only unnecessarily different, but it contaminated the notion of time intervals too - a second on a smear day isn’t a second on any other. 

The time interval (pair of points in time) doesn’t have a problem as long as these points are properly identified as SLOTH.  Durations, however, are a different issue — to compute a duration from an interval in the presence of smear is more work unless the application does not care about the 1.2e-5 inaccuracy. (*)

The point about smear is that those applications that care about time, but not about 1.2e-5 accuracy or implement (correct) leapsecond code, continue to work without breakage over a leapsecond.  Most people in data centers consider that an immense win (as do their customers and users :-).

Grüße, Carsten

(*) Maybe we should, selective-availability style, introduce some smear even if there is no leapsecond?
Might help debugging those smear-sensitive applications :-)

---

From: Joe Touch <[email-masked]>
Date: Wed, 31 Jan 2018 08:37:09 -0800

> It’s not — it’s just not on the table with most applications that are running on the Posix time scale.
OK, so I'll as "why?"

Here's my assumptions:

- the primary value in using Posix is for systems without external
interactions, e.g., where there is no way to obtain information about
newly scheduled leap events and where there is no way to synchronize to
an external time frame.

- once you add external I/O, I can't see a good reason not to just use
UTC because you now have all the information was missing that motivated
the use of Posix in the first place, and *every other time reference is
just as much work, but much less widely used* (and in some cases, more
challenging to compute - e.g., the floating point concerns I raised with
smearing).

However, I can see why some systems libraries might also support
conversion to "Google's time", in much the same way many time libraries
support conversion to other calendars, both past and present (Hindu,
Jewish, Navjo, Julian, Mayan, Incan, StarDate, etc.).

Joe

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 31 Jan 2018 23:31:16 +0100

> On Jan 31, 2018, at 17:37, Joe Touch <[email-masked]> wrote:
> 
> 
> 
> OK, so I'll as "why?”

Because a ton of legacy applications would have to be rewritten.

> Here's my assumptions:
> 
> - the primary value in using Posix is for systems without external interactions, e.g., where there is no way to obtain information about newly scheduled leap events and where there is no way to synchronize to an external time frame.

The primary value of using Posix is that it is the interface definition that governs the dominant operating system of the Web and a lot of software derived from that.

This is not the only place where Posix is broken.  It just mainly codified existing practice that already was broken (i.e., blame Ken Thompson not thinking about leap seconds in 1969, when the problem of UTC vs. TAI was still solved by a historical form of [whole-year] smearing — at least Unix time is no longer counting in 60ths of a second :-).

> - once you add external I/O, I can't see a good reason not to just use UTC because you now have all the information was missing that motivated the use of Posix in the first place, and *every other time reference is just as much work, but much less widely used* (and in some cases, more challenging to compute - e.g., the floating point concerns I raised with smearing).

If you are writing everything from scratch.  That’s not what happens.

By the way, RFC 7164 is a nice example of the problem becoming visible on a protocol that actually runs on systems that may implement (or ignore) leap seconds in different ways.
RFC 7164 recommends against basing RTP timestamps on smeared time.  Given that we Europeans are used to a 4 % increase in playback speed of movies, we are likely to be inclined to accept a 0.0016 % error that would be introduced by smearing here.

> However, I can see why some systems libraries might also support conversion to "Google's time", in much the same way many time libraries support conversion to other calendars, both past and present (Hindu, Jewish, Navjo, Julian, Mayan, Incan, StarDate, etc.).

Posix time already is the system time, both for applications that care about specifics of time (which might even know about the Jewish calendar) and the much larger class that don’t really but still have to deal with time somehow.

Grüße, Carsten

---

From: Joe Touch <[email-masked]>
Date: Wed, 31 Jan 2018 17:28:29 -0800

Carsten,

> Because a ton of legacy applications would have to be rewritten.

If you change this value they hold in what they think is Posix time to something else, it’ll break them in other unpredictable ways.

 That helps no one.

Joe

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 1 Feb 2018 07:28:38 +0100

> If you change this value they hold in what they think is Posix time to something else, it’ll break them in other unpredictable ways.

About as much as 1.2e-5 clock drift, which applications already had to contend with before.

Besides, the experiment already has been made in some very large sites, and site operators/reliability engineers liked the outcome.

No doubt, leapsecond smearing is wrong, impure, and a giant hack.
But the previous way in which Posix time worked is all these, too, plus it loses monotonicity and has a step function.

We haven’t put an indication of a time scale in draft-bormann-cbor-time-tag-01 yet (draft-bormann-cbor-time-tag-00 had one, but it wasn’t fully cooked).  Besides UTC, TAI, and real-time variants of these (UTC(PTB) etc., TAI as approximated towards UTC(USNO) a.k.a. “GPS time + 19 s”, ...), it would be useful to have a smeared leapsecond time scale in there (and preferably just one).  If the IETF can be instrumental in fostering and documenting some consensus here, this would be a big win.

Grüße, Carsten