Comment

Comment by cfreksen

I would say that the instance (or second long interval) in time that we name 2016-12-31T23:59:60Z is 1483228836 seconds after 1970-01-01T00:00:00Z, and that 2017-01-01T00:00:00Z is 1483228837 seconds after 1970-01-01T00:00:00Z [0].

The key here is that I use "seconds" to mean a fixed duration of time, like how long it takes light to travel 299792458 meters in a vacuum[1], and this version of seconds is independent of Earth orbiting the Sun, or the Earth spinning or anything like that[2]. If I understand you correctly, you use "seconds" more akin to how I use "days in a year": Most years have 365 days, but when certain dates starts to drift too far from some astronomical phenomenon we like to be aligned with (e.g. that the Northern Hemisphere has Summer Solstice around the 21st of June) we insert an extra day in some years (about every 4th year).

I haven't read RFC 9562 in detail, but if you use my version of "seconds" then "seconds since the Epoch" is a meaningful and monotonically increasing sequence. I suspect that some of the other commentors in this thread use this version of "seconds" and that some of the confusion/disagreement stems from this difference in definition.

The paragraph in Section 6.1 titled "Altering, Fuzzing, or Smearing" also seems relevant:

    > Implementations MAY alter the actual timestamp. Some examples include ..., 2) handle leap seconds ...
    > This specification makes no requirement or guarantee about how close the clock value needs to be to the actual time.
[0] Please forgive any off-by-one errors I might have made.

[1] I know that the SI definition between meters and seconds is the other way around, but I think my point is clearer this way.

[2] I ignore relativity as I don't think it is relevant here.

parent cfreksen 2 years ago

Discussion

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton