Node clock, leap seconds, and alignment with minutes

[JDLH]

In the Filecoin Specification for Nodes, section 2.6.10 Clock, the discussion of clock and time seems to be missing some grounding in timescale, and an acknowledgement of leap seconds.

The spec does not say that the Filecoin time values shall be in terms of the Universal Coordinated Time (UTC) timescale. I can't imagine that any other timescale would be practical. But it would good to say it explicitly.

One interesting detail about UTC is that it incorporates leap seconds. Thus, every 18 months or so, there is a minute which is 61 seconds long. What happens to Filecoin epochs when a leap second occurs? Is there an epoch which ends up being 31 seconds long? Does the epoch remain 30 seconds long, but all subsequent epoch boundaries are skewed with respect to clock minute boundaries?

The NTP website has an interesting paper, NTP Timescale and Leap Seconds. If I followed the paper correctly, it looks like NTP reflects leap seconds by making NTP time stand still during the leap second. The NTP time value, which is a count of seconds since a start time in 1900CE, does not increment during the leap second.

If Filecoin nodes synchronise to NTP, I think they will experience indicated time slowing down, and the Filecoin epoch which includes the leap second will be 31 seconds long, but all the timestamps will record it as 30 seconds long. However, a Filecoin node which takes the Clock section's suggestion, to use "local NTP/PTP servers with GPS references", might experience the leap second differently.

In a related topic, the glossary entry "Epoch" says, "Time in the Filecoin blockchain is discretized into epochs that are currently set to thirty (30) seconds in duration." The Clock section also mentions setting epoch number via dividing a time offset by epoch_time. Nothing there or in the Clock section either guarantees or rules out that epochs will start on whole- and half-minute boundaries. However, if I am reading correctly, the genesis block seems to have a Time value that is a whole number of minutes (0). It may be that all epochs will therefore always start on UTC whole-and half-minute boundaries. But it would be good to either specify that people either must not, or may, rely on this property. I would suggest specifying that they "must not" rely on it. The way Filecoin treats leap seconds will affect how epochs continue to align to minute boundaries.

A possible response to this issue is to add a sentence to the start of the Clock section, saying something like:

Filecoin time measurement is based on the Universal Coordinated Time (UTC) timescale. Filecoin assumes weak clock synchrony…

And also add a sentence to the end of the Clock requirements, saying something like:

All timestamps and time offsets shall be with respect to the Universal Coordinated Time (UTC) timescale. However, leap seconds shall be treated as clock drift errors, and shall be disregarded in calculating epoch numbers. (Note: the NTP protocol behaves this way.)

I am new to Filecoin, and I am reading these specifications in a naive way. Perhaps I am misunderstanding, in which case a different clarification to the specification would be better. However, in my experience as a software engineer, leap seconds tend to muddle a lot of specifications. I hope this is helpful.