Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add principle on use of delta seconds #467

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

torgo
Copy link
Member

@torgo torgo commented Jan 24, 2024

Addresses #344...


Preview | Diff

@cynthia
Copy link
Member

cynthia commented Jan 24, 2024

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.

Copy link
Member

@cynthia cynthia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't layered in the right place.

Copy link
Contributor

@martinthomson martinthomson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

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
Copy link
Contributor

@torgo torgo added this to the 2024-03-04-week milestone Mar 3, 2024
@torgo torgo modified the milestones: 2024-04-01-week, 2024-06-03-week Jun 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants