Subject: [Ntp] I-D Action: draft-roughtime-aanchal-01.txt

From: [email-masked]
Date: Mon, 11 Mar 2019 10:29:16 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Time Protocol WG of the IETF.

        Title           : Roughtime
        Authors         : Aanchal Malhotra
                          Adam Langley
                          Watson Ladd
	Filename        : draft-roughtime-aanchal-01.txt
	Pages           : 11
	Date            : 2019-03-11

Abstract:
   This document specifies Roughtime - a protocol that aims to achieve
   rough time synchronization while detecting servers that provide
   inaccurate time and providing cryptographic proof of their
   malfeasance.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-roughtime-aanchal/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-roughtime-aanchal-01
https://datatracker.ietf.org/doc/html/draft-roughtime-aanchal-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-roughtime-aanchal-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Thomas Peterson <[email-masked]>
Date: Wed, 13 Mar 2019 16:28:37 +0000

Thank you for publishing this new version of the draft.

Feedback:

* As was previously mentioned, tag names less than 4 characters are 
padded inconsistently - PAD\xff and SIG\x00. Please make these 
consistent and clear up the language towards the end of section 4 
explicitly state what shall be used for padding, as "... [using] hex 
escape codes at the end" is unclear.

* Section 5.2.1 and section 6 could have their language tidied up. What 
I believe this specification is proposing is TAI-based time with Unix 
epoch as its reference, however if that is the case and it is assumed 
that clients requesting time will be updating local clocks, should there 
not be explicit mentioning that clients SHOULD apply leap-seconds 
(unless configured otherwise) when performing an update? Perhaps having 
identical behaviour to, and reference to IEEE 1588 would be suggested here.

* I think that section 9 should be removed as documents aiming to be 
protocol specifications should not hold information about transient 
services implementing the protocol.

Regards

On 11/03/2019 17:29, [email-masked] wrote:
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: "Dieter Sibold" <[email-masked]>
Date: Wed, 13 Mar 2019 18:07:17 +0100

Many thanks for this documents. See comments below.

Dieter Sibold
[email-masked]

On 13 Mar 2019, at 17:28, Thomas Peterson wrote:

> * Section 5.2.1 and section 6 could have their language tidied up. 
> What I believe this specification is proposing is TAI-based time with 
> Unix epoch as its reference, however if that is the case and it is 
> assumed that clients requesting time will be updating local clocks, 
> should there not be explicit mentioning that clients SHOULD apply 
> leap-seconds (unless configured otherwise) when performing an update? 
> Perhaps having identical behaviour to, and reference to IEEE 1588 
> would be suggested here.
>

I agree with both statements and from my point of view this especially 
is needed for Sec. 6. Maybe, you already introduce  TAI (or UTC?) as the 
reference timescale for roughtime.

One small detail: Sec. 5.2., first sentence: the last listing probably 
should also contain the tag LEAP?

Regards
Dieter

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 14 Mar 2019 07:51:48 +0100

>>> Thomas Peterson <[email-masked]> schrieb am 13.03.2019 um 17:28
in
Nachricht <[email-masked]>:
> padded inconsistently ‑ PAD\xff and SIG\x00. Please make these 

I wonder whether it wouldn't be preferrable to use ACSII SPC for padding if
thas are ASCII anyway. Using  a binary zero as padding might have some
advantages for the C language, but that's probably all.

> I believe this specification is proposing is TAI‑based time with Unix 
> not be explicit mentioning that clients SHOULD apply leap‑seconds 
> On 11/03/2019 17:29, internet‑[email-masked] wrote:
>> A New Internet‑Draft is available from the on‑line Internet‑Drafts
directories.
>> 	Filename        : draft‑roughtime‑aanchal‑01.txt
>> 	Pages           : 11
>> 	Date            : 2019‑03‑11
>>
>> Abstract:
>>     This document specifies Roughtime ‑ a protocol that aims to achieve
>> https://datatracker.ietf.org/doc/draft‑roughtime‑aanchal/ 
>>
>> https://tools.ietf.org/html/draft‑roughtime‑aanchal‑01 
>> https://datatracker.ietf.org/doc/html/draft‑roughtime‑aanchal‑01 
>>
>> https://www.ietf.org/rfcdiff?url2=draft‑roughtime‑aanchal‑01 
>>
>>
>> Internet‑Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet‑drafts/ 
>>

---

From: Tal Mizrahi <[email-masked]>
Date: Thu, 14 Mar 2019 11:17:00 +0200

Dear authors,

Thanks for updating the draft.

Two comments.
1. Please clarify in the draft what is the threat that rough time addresses
that was not addressed with NTP (assuming multiple servers and
authentication). It looks like you are looking for a proof that a server is
a falseticker, which means the threat you are trying to address is a client
who falsely accuses a server of being a falseticker. Is this the case?
2. "If the time from the second server is before the first, then the client
has proof of misbehavior" - this is not necessarily true; let's say the
client sends a request to server 1 at time T1, receives a response, and
sends a request to server 2 at time T2. You have a hidden assumption that
if the two servers are truechimers, the offset between them must be less
than T2-T1, but that is not necessarily the case. If T2 is a short time
after T1, then the time from the second server may very well be before the
time from the first server. I would suggest to rephrase this sentence.

Cheers,
Tal.

---

From: Tal Mizrahi <[email-masked]>
Date: Thu, 14 Mar 2019 11:58:48 +0200

Dear authors,

I wonder if roughtime addresses the following threats. Will appreciate if
you can comment.

1. Does roughtime address delay attacks? Let's say we have a
man-in-the-middle who delays all responses from Server 1. The time acquired
from Server 1 would be faulty, but it looks like roughtime cannot prove
that Server 1 is a falseticker in this case. Conversely, the NTP
selection/clustering algorithm would detect Server 1 as a falseticker
(assuming there are enough truechimer servers).
2. It looks like roughtime mitigates clients who falsely accuse a server of
being a false ticker, but what about a client who tries to hide the
misbehavior of a server? For example, Server 1 is a falseticker - its time
is ahead of Server 2. The client sends a request to Server 1, then waits
for a sufficiently long time, and then sends a request to Server 2.
Roughtime will not detect there is a problem in this case, right?
3. A similar scenario to (2) above can be implemented by a delay attacker:
a man-in-the-middle who delays the request to Server 2. This attack will
cause the acquired time from Server 2 to be false, but will prevent the
misbehavior from  being detected by Roughtime.

Cheers,
Tal.

On Thu, Mar 14, 2019 at 11:17 AM Tal Mizrahi <[email-masked]>
wrote:

> 1. Please clarify in the draft what is the threat that rough time
> addresses that was not addressed with NTP (assuming multiple servers and
> 2. "If the time from the second server is before the first, then the
> client has proof of misbehavior" - this is not necessarily true; let's say
> the client sends a request to server 1 at time T1, receives a response, and

---

From: Thomas Peterson <[email-masked]>
Date: Thu, 14 Mar 2019 17:31:56 +0000

Responses inline.

Regards

On 14/03/2019 09:58, Tal Mizrahi wrote:
> Dear authors,
>
> I wonder if roughtime addresses the following threats. Will appreciate 
> if you can comment.
>
> man-in-the-middle who delays all responses from Server 1. The time 
> acquired from Server 1 would be faulty, but it looks like roughtime 
> cannot prove that Server 1 is a falseticker in this case. Conversely, 
> the NTP selection/clustering algorithm would detect Server 1 as a 
> falseticker (assuming there are enough truechimer servers).

I do not think that any protocol can effectively mitigate this for a 
given point of connectivity in the scenario where all packets are being 
actively delayed by a middlebox. I believe the only two mitigations are 
protocol obscurity/ambiguity (protocols difficult to identify on the 
wire for DPI purposes may be more difficult to deliberately delay), or 
via clients having greater link/path diversity bypassing the attacker.

> 2. It looks like roughtime mitigates clients who falsely accuse a 
> server of being a false ticker, but what about a client who tries to 
> hide the misbehavior of a server? For example, Server 1 is a 
> falseticker - its time is ahead of Server 2. The client sends a 
> request to Server 1, then waits for a sufficiently long time, and then 
> sends a request to Server 2. Roughtime will not detect there is a 
> problem in this case, right?
I believe you are correct and perhaps this scenario could be described 
as a risk in the draft.
> 3. A similar scenario to (2) above can be implemented by a delay 
> attacker: a man-in-the-middle who delays the request to Server 2. This 
> attack will cause the acquired time from Server 2 to be false, but 
> will prevent the misbehavior from  being detected by Roughtime.

This is also technically possible, however I believe the only real 
answer to some of these mitigations against middleboxes is a greater 
number of servers to query (given the low packet overheads, this should 
not be expensive), random querying of servers, and diversity in path as 
suggested above.

Where I think an area of greater focus should be on an middlebox 
intercepting reports of malfeasance, either modifying the data, or 
simply blocking it as for a malicious middlebox is a lower effort attack.

> Cheers,
> Tal.
>
> On Thu, Mar 14, 2019 at 11:17 AM Tal Mizrahi 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Dear authors,
>
>     addresses that was not addressed with NTP (assuming multiple
>     servers and authentication). It looks like you are looking for a
>     proof that a server is a falseticker, which means the threat you
>     are trying to address is a client who falsely accuses a server of
>     being a falseticker. Is this the case?
>     2. "If the time from the second server is before the first, then
>     the client has proof of misbehavior" - this is not necessarily
>     true; let's say the client sends a request to server 1 at time T1,
>     receives a response, and sends a request to server 2 at time T2.
>     You have a hidden assumption that if the two servers are
>     truechimers, the offset between them must be less than T2-T1, but
>     that is not necessarily the case. If T2 is a short time after T1,
>     then the time from the second server may very well be before the
>     On Mon, Mar 11, 2019 at 7:30 PM <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>
>         until the htmlized version and diff are available at
>         tools.ietf.org <http://tools.ietf.org>.
>
>         [email-masked] <mailto:[email-masked]>

---

From: Tal Mizrahi <[email-masked]>
Date: Sun, 17 Mar 2019 08:20:45 +0200

Hi Thomas,

Thanks for the detailed response.

I would suggest to clarify in the draft what Roughtime does and does not
do. Please let me know if I got it right:
- Roughtime is intended to prevent clients from falsely accusing servers of
being falsetickers.
- Roughtime does not prevent a client from hiding the faulty behavior of a
server.
- A falseticker can prevent Roughtime from ever detecting its faulty
behavior.
- A falseticker can prevent Roughtime from ever detecting the faulty
behavior of the server after it in the chain, or the server before it in
the chain.
- MITM attackers can also implement the behavior of the last two lines.

Please let me know if this makes sense.
Thanks,
Tal.

On Thu, Mar 14, 2019 at 7:31 PM Thomas Peterson <[email-masked]>
wrote:

> I do not think that any protocol can effectively mitigate this for a given
> point of connectivity in the scenario where all packets are being actively
> delayed by a middlebox. I believe the only two mitigations are protocol
> obscurity/ambiguity (protocols difficult to identify on the wire for DPI
> purposes may be more difficult to deliberately delay), or via clients
> having greater link/path diversity bypassing the attacker.
>
> 2. It looks like roughtime mitigates clients who falsely accuse a server
> of being a false ticker, but what about a client who tries to hide the
> I believe you are correct and perhaps this scenario could be described as
> a risk in the draft.
>
> This is also technically possible, however I believe the only real answer
> to some of these mitigations against middleboxes is a greater number of
> servers to query (given the low packet overheads, this should not be
> expensive), random querying of servers, and diversity in path as suggested
> above.
>
> intercepting reports of malfeasance, either modifying the data, or simply
> blocking it as for a malicious middlebox is a lower effort attack.
>
> Cheers,
> Tal.
>
> ntp mailing [email-masked]://www.ietf.org/mailman/listinfo/ntp
>
>

---

From: Thomas Peterson <[email-masked]>
Date: Mon, 18 Mar 2019 17:09:03 +0000

If by "falseticker" you are referring exclusively to a misbehaving 
client, I'm unsure if that makes complete sense particularly in the 4th 
statement. Could you clarify in both 3rd and 4th statements which you 
are referring to by a "falseticker", is that client or server?

Regards

On 17/03/2019 06:20, Tal Mizrahi wrote:
> I would suggest to clarify in the draft what Roughtime does and does 
> not do. Please let me know if I got it right:
> - Roughtime is intended to prevent clients from falsely accusing 
> servers of being falsetickers.
> - Roughtime does not prevent a client from hiding the faulty behavior 
> of a server.
> behavior of the server after it in the chain, or the server before it 
> in the chain.
> On Thu, Mar 14, 2019 at 7:31 PM Thomas Peterson 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Responses inline.
>
>     Regards
>
>
>>     I wonder if roughtime addresses the following threats. Will
>>     appreciate if you can comment.
>>
>>     man-in-the-middle who delays all responses from Server 1. The
>>     time acquired from Server 1 would be faulty, but it looks like
>>     roughtime cannot prove that Server 1 is a falseticker in this
>>     case. Conversely, the NTP selection/clustering algorithm would
>>     detect Server 1 as a falseticker (assuming there are enough
>>     truechimer servers).
>
>     I do not think that any protocol can effectively mitigate this for
>     a given point of connectivity in the scenario where all packets
>     are being actively delayed by a middlebox. I believe the only two
>     mitigations are protocol obscurity/ambiguity (protocols difficult
>     to identify on the wire for DPI purposes may be more difficult to
>     deliberately delay), or via clients having greater link/path
>     diversity bypassing the attacker.
>
>>     server of being a false ticker, but what about a client who tries
>>     to hide the misbehavior of a server? For example, Server 1 is a
>>     request to Server 1, then waits for a sufficiently long time, and
>>     then sends a request to Server 2. Roughtime will not detect there
>>     is a problem in this case, right?
>     I believe you are correct and perhaps this scenario could be
>     described as a risk in the draft.
>>     attacker: a man-in-the-middle who delays the request to Server 2.
>>     This attack will cause the acquired time from Server 2 to be
>>     false, but will prevent the misbehavior from  being detected by
>>     Roughtime.
>
>     answer to some of these mitigations against middleboxes is a
>     greater number of servers to query (given the low packet
>     overheads, this should not be expensive), random querying of
>     servers, and diversity in path as suggested above.
>
>>         1. Please clarify in the draft what is the threat that rough
>>         time addresses that was not addressed with NTP (assuming
>>         multiple servers and authentication). It looks like you are
>>         looking for a proof that a server is a falseticker, which
>>         means the threat you are trying to address is a client who
>>         falsely accuses a server of being a falseticker. Is this the
>>         case?
>>         2. "If the time from the second server is before the first,
>>         then the client has proof of misbehavior" - this is not
>>         necessarily true; let's say the client sends a request to
>>         server 1 at time T1, receives a response, and sends a request
>>         to server 2 at time T2. You have a hidden assumption that if
>>         the two servers are truechimers, the offset between them must
>>         be less than T2-T1, but that is not necessarily the case. If
>>         T2 is a short time after T1, then the time from the second
>>         server may very well be before the time from the first
>>         server. I would suggest to rephrase this sentence.
>>
>>         Cheers,
>>         Tal.
>>

---

From: Aanchal Malhotra <[email-masked]>
Date: Mon, 18 Mar 2019 17:07:28 -0700

Hi Thomas & Dieter,

Thanks for your comments.

> should also contain the tag LEAP?

I agree with all of the above. Will make the relevant changes in the next
version.

---

From: Aanchal Malhotra <[email-masked]>
Date: Mon, 18 Mar 2019 17:15:28 -0700

Hi Tal,

Thanks for the comments. See my response inline.

On Thu, Mar 14, 2019 at 2:17 AM Tal Mizrahi <[email-masked]>
wrote:

> authentication).

a) Roughtime aims to achieve rough time synchronisation in a secure way
that doesn't depend on any particular time server, and in such a way that,
if a time server does misbehave, clients end up with cryptographic proof of
it.
b)  Roughtime envisions to build an ecosystem (here
<https://roughtime.googlesource.com/roughtime/+/HEAD/ECOSYSTEM.md.>) which
includes 1) enabling the client to generate a crypto proof of server's
misbehaviour, 2) Curating server lists by having a list of "known good
servers" (something along the lines of Certificate transparency.)

We hope to address (b) in the next version of the draft.

> It looks like you are looking for a proof that a server is a falseticker,
> which means the threat you are trying to address is a client who falsely
> accuses a server of being a falseticker. Is this the case?
>

I am not sure how a client can falsely accuse a server of being a
falseticker with a cryptographic proof of misbehaviour. What am I missing?

> time from the first server. I would suggest to rephrase this sentence.

With every response, the server also tells the "RADI" which is the server's
estimate of the accuracy of MIDP at the time they compose the response
packet.
In Section 7, Cheater detection." A pair of responses (r_1, r_2) is invalid
if MIDP_1-RADI_1 > MIDP_2+RADI_2."
In Section 6, "Servers SHOULD use GPS or other realizations of TAI that
have been highly accurate in the past for Roughtime to meet their accuracy
promises."

 So if servers are truechimers, the offset must be lass than
(MIDP_2+RADI_2- MIDP_1-RADI_1)

---

From: Aanchal Malhotra <[email-masked]>
Date: Mon, 18 Mar 2019 17:22:30 -0700

Hi Tal,

On Sat, Mar 16, 2019 at 11:21 PM Tal Mizrahi <[email-masked]>
wrote:

> - Roughtime is intended to prevent clients from falsely accusing servers
> of being falsetickers.
>

 Roughtime is intended to enable clients to detect misbehaving servers with
a cryptographic proof of its misbehaviour that can be verified by third
party.

> - Roughtime does not prevent a client from hiding the faulty behavior of a

No, and this is not stated as one of the goals of Roughtime. Roughtime aims
to achieve rough time synchronisation in a secure way that doesn't depend
on any particular time server, and in such a way that, if a time server
does misbehave, clients end up with cryptographic proof of it. However, the
ultimate aim of Roughtime is to build an ecosystem
<https://roughtime.googlesource.com/roughtime/+/HEAD/ECOSYSTEM.md.> which
includes 1) Enabling the client to generate a proof of server's
misbehaviour, 2) Curating server lists by having a list of "known good
servers".
Such an ecosystem MAY address the above concern.

> behavior.

It depends on how you define falseticker. In Roughtime lang, if the time
reported by a server2 lies between that reported by the server1 before and
server3 after it, then it is not a falseticker. However, it could be
falseticker in the sense that it does not report the most accurate time.
Still the time reported by the server2 or the "falseticker" is bounded if
it wants to prevent detection as follow:

(MIDP_2+RADI_2 > MIDP_1-RADI_1) AND (MIDP_2-RADI_2 <  MIDP_3-RADI_3)

> the chain..

I hope that I have addressed the above concerns.

>> protocol obscurity/ambiguity (protocols difficult to identify on the wire
>> for DPI purposes may be more difficult to deliberately delay), or via
>> clients having greater link/path diversity bypassing the attacker.
>>
>> attack will cause the acquired time from Server 2 to be false, but will
>> prevent the misbehavior from  being detected by Roughtime.
>>

---

From: Tal Mizrahi <[email-masked]>
Date: Tue, 19 Mar 2019 07:33:17 +0200

Hi Thomas,

A falseticker is a misbehaving server. Misbehaving can refer to either a
maliciously or a malfunctioning server. I will clarify the 3rd and 4th
statements by examples.

behavior.

Details:
A falseticker's faulty behavior may be undetected if the falseticker delays
the response. Let's take an example: we have 3 time servers: S1, S2, S3.
Let's say that S2 is a falseticker.
- The client sends a request to S1 and receives a response with timestamp
T1.
- The client sends a request to S2 and receives a response with timestamp
T2. The response is delayed and sent by the server only at time T2'. In
this case let's say that T2'>T2 and that T2' is sufficiently larger than T2
to cause the client's time service to be compromised.
- The client sends a request to S3 and receives a response with timestamp
T3.
- Since T3>T2>T1, Roughtime does not detect a problem.
- However, the time that the client retrieves from S2 is off by about
(T2'-T2)/2, since the client assumes that the delay is symmetric.

This is an example of a falseticker that is not detected by Roughtime.

Details:
The key here is that as opposed to the clustering and combining in NTP,
Roughtime does not necessarily detect faulty servers. If you have two
successive faulty servers, such that one of them is wrong and the other is
malicious, then the malicious server can prevent the faulty behavior of
both servers from being detected by Roughtime.
Again, an example with S1,S2,S3. Let's say that S2 is malicious, and S3 is
just wrong (its clock is late).
- The client receives a timestamp T1 from S1, and sends a request to S2.
- S2 receives the request form the client, and generates a timestamp T2>T1.
- S2 now waits sufficiently long to make sure that the time in S3 is
greater than T2, and finally sends the response to the client.
- After the client sends the third request, we have T3>T2>T1.
- Roughtime does not detect the two faulty servers in this case.

Cheers,
Tal.

On Mon, Mar 18, 2019 at 7:09 PM Thomas Peterson <[email-masked]>
wrote:

> If by "falseticker" you are referring exclusively to a misbehaving client,
> I'm unsure if that makes complete sense particularly in the 4th statement.
> Could you clarify in both 3rd and 4th statements which you are referring to
> by a "falseticker", is that client or server?
>
> Regards
>
>

---

From: Tal Mizrahi <[email-masked]>
Date: Tue, 19 Mar 2019 07:42:49 +0200

Hi Aanchal,

Many thanks for the detailed response.
Please see my responses inline, marked [TM].

Cheers,
Tal.

> if a time server does misbehave, clients end up with cryptographic proof of

[TM] I don't think that Roughtime achieves this. Please see the examples I
gave in a separate mail to Thomas. Roughtime is not guaranteed to detect
misbehaving servers.

> <https://roughtime.googlesource.com/roughtime/+/HEAD/ECOSYSTEM.md.>)
> which includes 1) enabling the client to generate a crypto proof of
> server's misbehaviour, 2) Curating server lists by having a list of "known
> good servers" (something along the lines of Certificate transparency.)
>
>
[TM] Crypto can guarantee order, but it is not immune to delays. This is
why malfunctioning time servers, which delay messages (either maliciously
or otherwise) may go undetected by Roughtime.

> falseticker with a cryptographic proof of misbehaviour. What am I missing?

[TM] I agree. Roughtime indeed prevents a client from falsely accusing a
server of being a falseticker.

> With every response, the server also tells the "RADI" which is the
> server's estimate of the accuracy of MIDP at the time they compose the
> response packet.
> In Section 7, Cheater detection." A pair of responses (r_1, r_2) is
> invalid if MIDP_1-RADI_1 > MIDP_2+RADI_2."

---

From: Marcus Dansarie <[email-masked]>
Date: Tue, 19 Mar 2019 12:14:56 -0400

Will any of the authors of this draft be in Prague next week? I'd love
the opportunity to exchange thoughts and ideas with you there if possible.

I briefly discussed Roughtime with Peter Löthberg, whom some of you may
know. He was, to my surprise, positive to the idea of Roughtime but had
a few comments. I'll copy them verbatim below.

Kind regards,
Marcus

Peter's comments below:

Timescale:

- BIPM recommends to use UTC in all timing applications. They directly
  discourage the use of TAI.

  Solve the leap second in a proper way.

- UTC is a paper clock done after the fact. UTC(k) is a physical
  representation of UTC. A new protocol should indicate the (k) that
  is used and the maximum expected time error between the actual UTC(k)
  and the time given by the server.

  Example:  GPS has tractability to UTC(usno) with a published error, so
  	    add the local receiver error (antenna, amplifier, cables
            etc....)

  Ref:
https://www.bipm.org/en/bipm-services/timescales/time-ftp/Circular-T.html

Network:

- The server/protocol need to handle IPv6 MTU exceeded ICMP messages.
- Suggested smallest usable IP MTU to be 576 bytes
- Have a way for the client to ask for a minimum MTU response

---

From: Watson Ladd <[email-masked]>
Date: Tue, 19 Mar 2019 09:39:50 -0700

> the opportunity to exchange thoughts and ideas with you there if possible.

Aanchal and I will be there.

> https://www.bipm.org/en/bipm-services/timescales/time-ftp/Circular-T.html

Please provide the text that provides a monotonic counter. I'm aware
of the argument that we should use an hh:mm:ss representation, and
would be happy to switch. But it must be monotonic. Neither of us are
experts in this area.
> - Have a way for the client to ask for a minimum MTU response

IPv6 MTU is 1280 bytes. Good point we need to think harder about it.

---

From: Ragnar Sundblad <[email-masked]>
Date: Wed, 20 Mar 2019 09:42:48 +0100

> On 19 Mar 2019, at 17:39, Watson Ladd <watson=[email-masked]> wrote:
...
> would be happy to switch. But it must be monotonic. Neither of us are
...

What kind of text is it that you are looking for?

The 23:59:60 representation is one, but there are of course also many
other possible alternatives, e.g. having a “+1” flag that you set for
a 23:59:60 timestamp (perhaps not pretty but may be useful), or having
a number-of-day (e.g. MJD) + number-of-second-this-day (that could be
86400 during an extra leap second) scheme, or many others.

Many other protocols have more or less problems with this, and if not
the protocols, many implementations have, sometimes because of vague
specifications. It would be nice if new protocols could get a clean,
simple, unambiguous representation.

(I have a well-known brand GPS receiver that inserts the UTC leap second
when the GPS time changes day, the next time this will be 19 seconds
before the actual UTC leap second).

Best regards,

/ragge

---

From: Thomas Peterson <[email-masked]>
Date: Wed, 20 Mar 2019 15:51:30 +0000

Thank you for this feedback.

Could either yourself or Peter provide further explanation on BIPM's 
rationale for recommending UTC in timing applications, and specifically 
why a protocol using TAI with leap seconds as a separate value is a bad 
idea? In the current draft we leave the task of applying leap seconds 
not exclusively up to the time synchronisation service (the Roughtime 
client making system call(s) to adjust clock) but it could be left to 
some other service in the system or not performed. Operating systems 
using IANA's tzdata database already access to historical and known 
future leap second offsets, making this mode of operation possible.

Regards

---

From: Tony Finch <[email-masked]>
Date: Thu, 21 Mar 2019 11:41:18 +0000

Re. section 6, I think the draft shoule explicitly point out that this is
the PTP time scale NOT the POSIX time scale, and that its offsets relative
to the NTP and POSIX time scales vary by the number of leap seconds.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Isle of Man: South or southwest 3 or 4, increasing 5 at times, then increasing
5 or 6 later. Slight, becoming mainly moderate. Mainly fair, occasionally
drizzle later. Moderate or good, occasionally poor.

---

From: Daniel Franke <[email-masked]>
Date: Thu, 21 Mar 2019 08:13:51 -0400

I think it would be prudent to use some epoch other than the UNIX
epoch, so that anything which misinterprets the timestamp as an
ordinary UNIX timestamp will break in an obvious manner rather than a
subtle one.

---

From: Thomas Peterson <[email-masked]>
Date: Thu, 21 Mar 2019 17:33:18 +0000

Could you please suggest a more suitable epoch instead? For current and 
future implementors, most I presume will be using a UNIX-like operating 
system like Linux and thus would ease implementation. A different epoch 
would require impementors have to calculate and store different offsets 
to their operating system's epoch in order to set the system's clock 
which feels to me as unnecessary.

Regards

---

From: Marcus Dansarie <[email-masked]>
Date: Thu, 21 Mar 2019 21:06:27 -0400

Peter also suggested using MJD + time since midnight. That solution
avoids ambiguities due to past leap seconds and is operating system
agnostic.

/Marcus

---

From: Tony Finch <[email-masked]>
Date: Fri, 22 Mar 2019 12:22:09 +0000

Thomas Peterson <[email-masked]> wrote:

> Could you please suggest a more suitable epoch instead?

I don't know of an existing standard other than PTP. (Neither TAI nor GPS
are a simple count of seconds.)

> For current and future implementors, most I presume will be using a
> UNIX-like operating system like Linux and thus would ease
> implementation. A different epoch would require impementors have to
> calculate and store different offsets to their operating system's epoch
> in order to set the system's clock which feels to me as unnecessary.

The current roughtime spec is not compatible with POSIX time and requires
implementers to obtain the leap second offset to set the system time. If
you wanted an easy implementation you would use POSIX or NTP time, and
forbid queries and responses around the time of a leap second.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
responsible stewardship of the earth and its resources

---

From: Daniel Franke <[email-masked]>
Date: Tue, 26 Mar 2019 13:27:18 +0100

> forbid queries and responses around the time of a leap second.

The current draft provides the TAI-UTC offset inline via the LEAP tag,
as I suggested in response to the previous draft.

However, I do note that the current draft implements only part of what
I recommended, and I think it would be further improved by doing the
rest of it as well. To reiterate what I recommended, in place of the
current LEAP tag, provide the following three tags:

MRLS - a TAI timestamp representing the time at which the
most-recently published leap second ends. This may be in either the
future or the past.

LSDI - A bit indicating whether the leap second given in MRLS is an
insertion or a deletion.

UTCO - What the TAI-UTC offset was or will be as of the time given in MRLS.

The motivation for representing leap seconds in this manner is that,
while we don't want to send smeared time over the wire, we do expect
that Roughtime clients will want to compute smeared time on their own
so that they can provide it to applications that are ignorant of leap
seconds and rely on the UNIX timescale. The scheme in the current
draft provides no advance warning of leap seconds; clients only find
about them by seeing the TAI-UTC offset change after the have
occurred. It would be better if clients could learn about them in
advance and begin their smear ahead of time, so that they never off by
more than half a second.

To be clear, I am not calling for Roughtime to prescribe any
particular smearing formula, just to provide all the information that
clients need in order to do something optimal.

---

From: Watson Ladd <[email-masked]>
Date: Tue, 26 Mar 2019 13:30:04 +0100

> clients need in order to do something optimal.

Does GPS provide all this information or equivalent? If so it would be simple
to include from an implementation/operation perspective.

---

From: Thomas Peterson <[email-masked]>
Date: Tue, 26 Mar 2019 12:34:20 +0000

GPS does not. Information about leap seconds come from a different 
channel - the explanation on 
https://data.iana.org/time-zones/tzdb/leap-seconds.list provides a good 
explanation. This leap second data is then distributed by operating 
system vendors accordingly.

Regards

---

From: Aanchal Malhotra <[email-masked]>
Date: Tue, 26 Mar 2019 13:35:01 +0100

GPS-TAI has a constant offset of 19 seconds.

-- 
Sent from iPhone

---

From: Tony Finch <[email-masked]>
Date: Tue, 26 Mar 2019 12:38:19 +0000

> as I suggested in response to the previous draft.

Yes, that makes it easier :-) But a LEAP offset isn't enough to recover
UTC since a client can't tell when the time is :60 so servers still have
to avoid talking about the time around a leap second.

I like your suggestion of providing the actual time of the leap and
insert/delete bits.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
the quest for freedom and justice can never end

---

From: Daniel Franke <[email-masked]>
Date: Tue, 26 Mar 2019 13:39:22 +0100

> system vendors accordingly.

Indeed, sadly there is NO standard end-to-end mechanism for
communicating leap seconds from IERS to the rest of the world.
https://data.iana.org/time-zones/tzdb/leap-seconds.list is the best
thing we've got right now. Somebody recently pointed me at
https://pairlist6.pair.net/pipermail/leapsecs/2019-January/007070.html
which discusses how this has been a pain point ever since the birth of
UTC, and how CCIR was warned about this and decided to do nothing
about it.

---

From: Marcus Dansarie <[email-masked]>
Date: Tue, 26 Mar 2019 13:41:27 +0100

The current offset between GPS system time and UTC is provided in a
field transmitted by the GPS satellites. What time that a GPS receiver
provides over its interfaces is implementation dependent - it's normally
UTC. Some GPS receivers output GPS time until they have correctly
decoded the UTC offset field upon which they immediately switch to UTC...

/Marcus

On 2019-03-26 13:35, Aanchal Malhotra wrote:
> On Tue, Mar 26, 2019 at 1:31 PM Watson Ladd
> <watson=[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     On Tue, Mar 26, 2019 at 1:28 PM Daniel Franke <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
>     > On Fri, Mar 22, 2019 at 1:22 PM Tony Finch <[email-masked]
>     <mailto:[email-masked]>> wrote:

---

From: Tony Finch <[email-masked]>
Date: Tue, 26 Mar 2019 13:35:47 +0000

Watson Ladd <[email-masked]> wrote:
>
> Does GPS provide all this information or equivalent? If so it would
> be simple to include from an implementation/operation perspective.

I think the answer is "yes, but..."

For the GPS details, see https://www.gps.gov/technical/icwg/IS-GPS-200J.pdf
sub-sub-sub-sub-sub-section 20.3.3.5.2.4

For some caveats, see http://catb.org/gpsd/hacking.html#y2k1

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Southeast Iceland: Westerly or southwesterly 5 to 7, increasing gale 8 at
times, perhaps severe gale 9 later in north. Very rough, becoming rough for a
time. Rain later. Moderate or good.

---

From: Martin Burnicki <[email-masked]>
Date: Wed, 27 Mar 2019 10:46:30 +0100

> system vendors accordingly.

This file is only a copy of one of the leap second files provided by
IERS, NIST, or USNO. See:
https://kb.meinbergglobal.com/kb/time_sync/ntp/configuration/ntp_leap_second_file

The problem with this file (or a similar one) is that an update of the
information is only possible via a software update from the vendor or
distributor. If a device is out of support it won't get any more updates
of this file.

An alternative would be to use the tzdist protocol which still has to
become more popular to get more acceptance:
https://kb.meinbergglobal.com/kb/time_sync/tzdist

Also, Poul-Henning Kamp proposed to use DNS to distribute leap second
announcements and the current TAI offset. This is much easier than
distributing a leap second file and standard runtime library calls can
be used to implement this. The idea is to to let a function like
getaddrinfo() resolve a specific hostname, but don't interpret the
returned number as IPv4 address. Instead decode it in a specific way to
extract leap second information and TAI offset from the returned bit
pattern. See:

"20151122 - Leapseconds via DNS"
http://phk.freebsd.dk/time/20151122.html

Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: [email-masked]
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy

---

From: Martin Burnicki <[email-masked]>
Date: Wed, 27 Mar 2019 10:50:23 +0100

> UTC, and how CCIR was warned about this and decided to do nothing

There are alternatives, see my reply to Thomas Peterson.

The problem is (as usual) that nobody starts using this because it's not
widespread, and it doesn't become whitespread since nobody is using it,
even though these alternatives would solve some problems. :-(

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Wed, 27 Mar 2019 10:55:51 +0100

> decoded the UTC offset field upon which they immediately switch to UTC...

There are also GPS receiver models out there where the "UTC correction"
data set sent by the satellites can be retrieved from the receiver, so
the current GPS/UTC offset can be determined, and the the TAI/UTC offset
can be easily computed since the GPS/TAI is known and constant.

So this could be an alternate approach to get the current UTC/TAI offset.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Thomas Peterson <[email-masked]>
Date: Wed, 27 Mar 2019 10:07:35 +0000

Your link to PHK's article appears to 404, but it appears available in 
the Wayback Machine:

http://web.archive.org/web/20160327041232/http://phk.freebsd.dk/time/20151122.html

I don't think necessarily that tzdata being the primary distribution 
today of leap seconds is a significant issue, as updates to leap seconds 
come only twice a year. However, I definitely see a benefit and support 
a time protocol like Roughtime which can transmit leap second data (but 
perhaps not older historical values), especially for embedded clients 
which may not have tzdata or a subset provided. I am unsure if the 
additional fields Daniel Franke has suggested are the right answer, but 
that appears to be the right direction to continue down should there be 
consensus of continuing not to use UTC.

Regards

---

From: Martin Burnicki <[email-masked]>
Date: Wed, 27 Mar 2019 16:08:10 +0100

> http://web.archive.org/web/20160327041232/http://phk.freebsd.dk/time/20151122.html

Thanks for the hint. I just copied it from my collection of links.

Looks like PHK has reorganized his home page, and now all links have a
new format. The original page is now at:
http://phk.freebsd.dk/time/20151122/

> consensus of continuing not to use UTC.

But even if you have a protocol like roughtime, this kind of information
has to be provided at some point in some way, for example using a
leapsecond file.

The problem arises if the leap second file isn't updated anymore because
no more tzdata updates become available. In this case it would be good
to have a different way to update the information, and not having to
rely on package updates for a specific OS version or distro.

Martin--
Martin Burnicki

Senior Software Engineer

---

From: Daniel Franke <[email-masked]>
Date: Wed, 27 Mar 2019 16:24:00 +0100

> rely on package updates for a specific OS version or distro.

The ultimate source of authoritative truth for leap second data is the
IERS. In a perfect world they'd commit to running infrastructure that
provides this data through a stable and documented API. Currently they
aren't doing this; they're just providing bulletins like
https://datacenter.iers.org/data/latestVersion/16_BULLETIN_C16.txt
intended for human rather than machine consumption. So unless and
until that situation changes, we need to rely on some other trusted
authority to disseminate accurate data in a format we can use. Right
now, the IANA leap second file is the best we've got. I don't think
there's any way we can improve at layer 7 before we first improve at
layer 8.

---

From: Martin Burnicki <[email-masked]>
Date: Wed, 27 Mar 2019 16:35:56 +0100

Daniel Franke wrote:
> IERS.

True.

> In a perfect world they'd commit to running infrastructure that
> intended for human rather than machine consumption.

And in addition, after I had asked them a couple of years ago to do so,
they also provide a leap second file in the same format as you grab from
tzdata:
https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list

This file is directly available at IERS, and you don't have to wait until

 - the tzdata folks have grabbed a new version of that file from NIST
 - they have updated that file in tzdata
 - they have then released a new version of the tdata package
 - and your distro maintainer has made a new tzdata package available

> So unless and

If you pick up the file directly from the authoritative source you avoid
a couple of steps that can potentially fail.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: "Dieter Sibold" <[email-masked]>
Date: Wed, 27 Mar 2019 16:38:07 +0100

Dieter Sibold
[email-masked]

> https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list

You can find this link also in the BCP draft.

---

From: Daniel Franke <[email-masked]>
Date: Wed, 27 Mar 2019 16:53:30 +0100

> https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list

Ah, that's good news and gets us a bit closer to solving the problem.
But IERS would probably be unhappy with us if we directed every
Roughtime server in the world to hard-code that URL, so we still need
to sort out a distribution mechanism.

---

From: Tony Finch <[email-masked]>
Date: Wed, 27 Mar 2019 16:08:29 +0000

> https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list

They have provided that information in their own format since 2013
https://web.archive.org/web/20130621114124/http://hpiers.obspm.fr/iers/bul/bulc/
(see the Leap_Second_History.dat file)

And the UTC-TAI.history file goes back to 1997
https://web.archive.org/web/19971014160340/http://hpiers.obspm.fr/iers/bul/bulc/

So machine readable tables have been available for a while although the
file formats are not particularly convenient.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
work to the benefit of all

---

From: Watson Ladd <[email-masked]>
Date: Wed, 27 Mar 2019 17:18:39 +0100

Roughtime is going to do MJD plus time since midnight, with some allowance
so problem of leap seconds in queries and responses to translate into UTC
is a nonissue.

Thanks to the Netnod team for explaining it to us, and I hope the formulas
I will soon put into the draft (for -02 in as many months!) are correct.

Comments welcome.

Sincerely,
Watson

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 27 Mar 2019 16:24:32 +0000

Perhaps some CDN wants to offer it.

---

From: Martin Burnicki <[email-masked]>
Date: Wed, 27 Mar 2019 17:24:36 +0100

> file formats are not particularly convenient.

Yes I know.

However, the leap-seconds.list file is in the format introduced by Judah
Levine (NIST) and David L. Mills (NTP) in 2000, which has also made it
into the tzdata package, and which can directly be used with ntpd:

"USING THE NETWORK TIME PROTOCOL (NTP)
TO TRANSMIT INTERNATIONAL ATOMIC TIME (TAI)"
https://tycho.usno.navy.mil/ptti/2000papers/paper34.pdf

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Wed, 27 Mar 2019 17:49:15 +0100

Watson Ladd wrote:
> Roughtime is going to do MJD plus time since midnight, with some
> allowance so problem of leap seconds in queries and responses to
> translate into UTC is a nonissue.

Hm, not even if you have to relate it to UTC and/or TAI at some point?

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 28 Mar 2019 08:32:07 +0100

>>> Martin Burnicki <[email-masked]> schrieb am 27.03.2019 um
16:35 in
> https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list 

Let me dream: If they'd provide a git repository (maybe on github) where the
current file is committed with a cryptographically signed tag (git tag -s),
global distribution and decentral verification would be quite easy, and a
periodic "git pull" would get you the current file very efficiently...

Git is just one example of a decentral file management, but these days it's
quite common-spread.

Ulrich

---

From: Thomas Peterson <[email-masked]>
Date: Thu, 28 Mar 2019 14:30:58 +0000

I would like to know more details about the rationale of choosing this 
over the previous two - by going down this path it appears Roughtime 
ceases to provide leap second information, except potentially as 
ancillary, something I feel is a negative for the protocol, amongst 
other concerns I have.

Regards

On 27/03/2019 16:18, Watson Ladd wrote:
> Thanks to the Netnod team for explaining it to us, and I hope the 
> formulas I will soon put into the draft (for -02 in as many months!) 
> are correct.
>
> Comments welcome.
>
> Sincerely,
> Watson

---

From: Watson Ladd <[email-masked]>
Date: Thu, 28 Mar 2019 15:33:28 +0100

> ancillary, something I feel is a negative for the protocol, amongst

The rational is it is easy to convert to POSIX time, monotonic, and
provided by your favorite GNSS/observatory.

I'd like to hear concerns: this seemed like the best option but should be
discussed on the list.

---

From: Tony Finch <[email-masked]>
Date: Thu, 28 Mar 2019 15:41:25 +0000

> I'd like to hear concerns: this seemed like the best option but should be

A client can't easily do leap smear if it only has MJD plus time since
midnight: it needs early warning of an upcoming leap second so that it
can start smearing at the right time.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forth: Southwest 5 or 6. Slight or moderate. Fair. Good.

---

From: Tony Finch <[email-masked]>
Date: Thu, 28 Mar 2019 15:46:14 +0000

> periodic "git pull" would get you the current file very efficiently...

If you are willing to trust me :-) you can get a cryptographically
signed leap second table in various formats using a DNS lookup of
leapsecond.dotat.at (ask for HINFO records to get a terse summary
of the formats).

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Mull of Galloway to Mull of Kintyre including the Firth of Clyde and North
Channel: Southwesterly 3 or 4, backing southerly 4 or 5. Slight, occasionally
moderate in west. Fair. Good.

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 28 Mar 2019 16:52:27 +0100

> can start smearing at the right time.

By the way: I remember I saw MJD in most cases related to a day number
or date, and time-of-day with at most 1 s resolution.

On the other hand, I *think* I remember that MJD follows UT1, not UTC,
since UT1 is more appropriate for usage by astronomers.

If this is correct then you would also have to apply a UT1/UTC
correction if you want sub-second precision and have to relate MJD to
TAI or UTC. Anybody knows if this is true, or is my memory fooling me?

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Tony Finch <[email-masked]>
Date: Thu, 28 Mar 2019 16:34:50 +0000

> since UT1 is more appropriate for usage by astronomers.

My understanding is that MJD can be used relative to any time scale, e.g.
it makes sense to refer to moments using MJD in UT1 or TT or sidereal time
etc. A better place to get an answer to this is probably the leapsecs
list, since it has resident astronomers :-)

For this particular purpose, it should be enough to have some words
explaining that the MJD number is being used as a representation of the
date in UTC truncated to an integer number of days since 1858-11-17.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Northwest Viking: Southwesterly 6 to gale 8. Rough, occasionally very rough.
Rain later. Good, occasionally moderate later.

---

From: Steve Allen <[email-masked]>
Date: Thu, 28 Mar 2019 09:38:58 -0700

> since UT1 is more appropriate for usage by astronomers.

According to various IAU resolutions MJD can be expressed in any of
several different time scales.  Those resolutions also say that the
time scale should be explicitly indicated.

According to astronomical guides for practical implementation MJD is
problematic at a precision of one second when the time scale is UTC.
That is for the same reason that it is prolematic for POSIX, because
UTC is the only time scale where the duration of one day is determined
by a measuring a different physical process than the duration of one
second.

> TAI or UTC. Anybody knows if this is true, or is my memory fooling me?

It is worth noting that in astronomy the decision was made before the
first leap second that no tabulations in almanacs use UTC.
Tabulations use other time scales (typically Terrestrial Time and
Universal Time).  UTC is used when timestamping observed events.

If a precision time scale is based on UTC using both days and seconds
then that should include explicit guidelines on how it is implemented
on days with leap seconds.

--
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           https://www.ucolick.org/~sla/  Hgt +250 m

---

From: Warner Losh <[email-masked]>
Date: Thu, 28 Mar 2019 19:45:48 -0600

> on days with leap seconds.

Clarity of implementation details is a must when you use MJD. There seems
to be no standards at all for its use. I've seen variously the last second
ignored (so all days have 86400) when MJD was expressed as a fraction (eg
MJD 12.345). I've seen 86401 used on leap day, I've seen MJD + a count of
seconds and  MJD + UTC-like time of day indication. All of these from
various data sources I had to deal with years ago. Sometimes what was going
on was clear, other times it was less so an I only found out about
surprising details by, for example, noticing that the fractional times were
slightly off for leap day... All of these were for UTC times expressed as a
MJD + offset from midnight. All of these show Steve's point about it being
problematic for POSIX...

Warner

---

From: Ragnar Sundblad <[email-masked]>
Date: Fri, 29 Mar 2019 03:45:36 +0100

> On 29 Mar 2019, at 02:45, Warner Losh <[email-masked]> wrote:
> 
> 
> 

Yes - if you use non-integer MJD and let the fractional part tell how
far into the day you are, such that MJD 58571.750000 would represent
2019-03-29 18:00:00 (Year-Month-Day Hours:Minutes:Seconds) on a
non-leap-second day, there is a problem on a day with an extra leap
second since the fractional part that day means 1/86400 more.
If this day would have an extra leap second, it would translate to
2019-03-29 18:00:00.75, or 3/4 more seconds.

This is _not_ what is proposed for Roughtime.

> Clarity of implementation details is a must when you use MJD. There seems to be no standards at all for its use. I've seen variously the last second ignored (so all days have 86400) when MJD was expressed as a fraction (eg MJD 12.345). I've seen 86401 used on leap day, I've seen MJD + a count of seconds and  MJD + UTC-like time of day indication. All of these from various data sources I had to deal with years ago. Sometimes what was going on was clear, other times it was less so an I only found out about surprising details by, for example, noticing that the fractional times were slightly off for leap day... All of these were for UTC times expressed as a MJD + offset from midnight. All of these show Steve's point about it being problematic for POSIX…

I beg to differ.
It does not show that it is being problematic to POSIX.
It shows, as you say, that the format and usage must be defined.
The same is true for every timescale I know about, I believe.

The proposed format, with an integer MJD to tell the day + offset from
midnight in a unit related to SI seconds should be unambiguous for
representing UTC.
It is equivalent to a Year-Month-DayOfMonth
Hours:Minutes:Seconds(.Fractions) representation, it just has
fewer numbers.

/ragge

---

From: Martin Burnicki <[email-masked]>
Date: Fri, 29 Mar 2019 09:38:22 +0100

Steve and Tony,

> on days with leap seconds.

Thanks for these details.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Fri, 29 Mar 2019 09:41:13 +0100

Warner Losh wrote:
> Clarity of implementation details is a must when you use MJD. There
> seems to be no standards at all for its use. I've seen variously the
> last second ignored (so all days have 86400) when MJD was expressed as a
> fraction (eg MJD 12.345). I've seen 86401 used on leap day, I've seen
> MJD + a count of seconds and  MJD + UTC-like time of day indication. All
> of these from various data sources I had to deal with years ago.
> Sometimes what was going on was clear, other times it was less so an I
> only found out about surprising details by, for example, noticing that
> the fractional times were slightly off for leap day... All of these were
> for UTC times expressed as a MJD + offset from midnight. All of these
> show Steve's point about it being problematic for POSIX...

So this doesn't sound like using MJD is the solution for all problems
with UTC. ;-)

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Ragnar Sundblad <[email-masked]>
Date: Fri, 29 Mar 2019 09:58:31 +0100

> On 29 Mar 2019, at 09:41, Martin Burnicki <[email-masked]> wrote:
> 
> Warner Losh wrote:

It is a time representation format.
I do not think anyone has said that it solves all problems with UTC.

It certainly is better for UTC than e.g. POSIX timestamps, since
there actually is a representation for a positive leap second, 23:59:60.

There are I suppose an unlimited number of ways to achieve the same
thing. This way is not entirely invented from scratch though.

/ragge