Add principle on use of delta seconds

[torgo]

Addresses #344...

---

Preview | Diff

[cynthia]

I think this should be moved into this section: "Use milliseconds for time measurement" as a conditional for cases where the time crosses boundaries that require interacting with HTTP headers.

[cynthia]

This isn't layered in the right place.

[martinthomson]

All of this is true, but I question whether this rises to a level at which it is necessary to capture here.

The HTTP working group maintains guidance on the use of that protocol and this is not in that envelope.

The underlying fact here is that not everyone has a clock that has the same date and time. What is documented here are some of the consequences of that, but there are many other consequences too. In particular, this whole business about clock sync is too much for me.

Is there a context in which this sort of guidance would have helped? That is, relative to the application of a bit of experience or common sense (which is what I see in #344).

I might instead say something like:

Do not assume that everyone has the same view of the time

Consider the potential for different entities to have divergent views of what the current time is.
If your design uses time, implement safeguards against disagreements about the current time.

This is not about time zones,
though that problem can often be addressed by using UTC
in machine-to-machine interfaces.
Time zones only apply at the point that there is a need to present localized information.

The web is comprised of many computers,
most of which have clocks,
but very few of which agree about the current time.
Some computers will have clocks that disagree by a lot.
Though clocks might disagree on the current time,
they disagree less about the rate at which time advances.

Using differences in time relative to a common reference point - rather than absolute times -
can help avoid problems arising from disagreements.
Even then, include allowances for clocks that drift,
especially when time passes.

An approximate agreement about the current time can be critical to security,
such as in determining certificate validity periods when authenticating servers.
In such cases, agreeing about the current time cannot be avoided;
being tolerant of errors is instead recommended.

I didn't add anything about the fact that even a single computer can have multiple time systems. For instance, media processing logic - audio in particular - can use a different oscillator from the main system clock. That's probably a detail that is specialized enough that we can rely on the people who need to know already knowing.

[LeaVerou]

The HTTP working group maintains guidance on the use of that protocol and this is not in that envelope.

Generally, we do have principles that are concrete guidance about specific web technologies. If the HTTP WG maintains a separate principles document, we should link to it, could you please share it?

[martinthomson]

https://httpwg.org/specs/rfc9205.html