Subject: [Acme] time in the specification

From: Josh Soref <[email-masked]>
Date: Mon, 20 Feb 2017 00:14:38 -0500

There are lines of the form:
>  "expires": "2016-01-01T00:00:00Z",

It would be helpful if the specification defined what time "now" was
either generally for things in the specification, or for each blob.
It's probably possible to include a "Date" field in most response
headers (I'm less certain about requests).

---

From: Richard Barnes <[email-masked]>
Date: Mon, 20 Feb 2017 07:38:20 -0500

What's the use case for this?  Diagnosing clock issues?

On Feb 20, 2017 12:14 AM, "Josh Soref" <[email-masked]> wrote:

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

---

From: Josh Soref <[email-masked]>
Date: Mon, 20 Feb 2017 08:31:57 -0500

Richard Barnes wrote:

Sometimes the spec lists an expires time and says what to do if time is
before/after. It's hard to tell if the time in a response is supposed to be
in the future when it's in fact in the past.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 21 Feb 2017 10:50:23 +1100

> in the future when it's in fact in the past.

HTTP provides a Date header field if you want to go crazy.  I would
probably still NTP over that though.

---

From: Richard Barnes <[email-masked]>
Date: Mon, 20 Feb 2017 19:40:19 -0500

> probably still NTP over that though.

The dates are all advisory anyway.  The real comparisons are the ones the
server does with its own clock; the "expires" attributes are just advice to
the client on how quickly they should be getting things done.

So I'm not tremendously worried about clock desync here.  The Date header
seems sufficient if clients want to try to figure out why their queries are
failing.

--Richard