Mention that incremental time does not count leap seconds, leap years or DST

[axelkar]

And add that wall time and field-based time do count leap years, DST and past leap seconds.

Please correct me if I'm wrong.

[axelkar]

Actually, there are three forms of incremental time important to this discussion:

• International Atomic Time (TAI)

  Rate of change never changes. Zero ghost times.

• UTC

  Adds or removes seconds called leap seconds to stay in sync with observed time (UT1). Adds the concept of days to support leap seconds.

• Unix time (APIs: CLOCK_REALTIME in POSIX, std::time::SystemTime in Rust)

  Leap seconds (and DST, if these APIs are using it. Windows?) can bring ghost times as explained below, which makes this non-contiguous when compared to UTC or TAI.

  Leap seconds are ambiguous to users of UTC that assume that a single day is 86400 seconds. It may look like the clock is jumping back and repeating a second when it moves from 23:59:60.999 to 00:00:00.000.

  It's ambiguous but with a calendar reintroducing days on top of Unix time, something like 2024-12-31 23:59:59.999, 1ms later 2024-12-31 23:59:59.000, then a second later 2025-01-01 00:00:00.000.

Could you also specify that wall time is the same as civil time?

[aphillips]

I think your issue title might be confused (backwards)?

Incremental time is just a number of clock ticks since an arbitrary epoch. Any field computation on an incremental time depends on a calendar and at least an LTO (defaulting to UTC, or, ideally, a timezone instead of an LTO).

Incremental times, thus, have nothing to do with DST or leap years or even leap seconds, since it is the calendar and/or time zone that deals with these concepts when converting the monotonic time into date/time field values.

Leap seconds are a special topic. In general, many systems and specifications (HTML is one such) ignore leap seconds and work in a proleptic manner (usually the error builds up the further back in time you look). This is bad for certain applications, but for most applications, since there are only 27 total leap seconds and since hardware clocks are often not that accurate, it's not specifically important. Millisecond accuracy is not usually expected for events in 1972 CE.

As you note, system time can "jump around" because of changes to the system clock. Most applications do not notice non-contiguous non-monotonic time because they are not watching the clock's value, only querying it sporadically (they also assume that the close was set correctly at some point--not always a good assumption!). Large jumps can occur, such as when the system's internet connection is down.

I think your notes are interesting and useful to the discussion in the document and I'll look for a way to incorporate them.

Could you also specify that wall time is the same as civil time?

Good call out.

[axelkar]

I think your issue title might be confused (backwards)?

Yes. I hope the document will contain more information around the topics I mentioned, to correct me.

Incremental time is just a number of clock ticks since an arbitrary epoch. Any field computation on an incremental time depends on a calendar and at least an LTO (defaulting to UTC, or, ideally, a timezone instead of an LTO).

I'm guessing LTO means something like local time offset?

Incremental times, thus, have nothing to do with DST or leap years or even leap seconds, since it is the calendar and/or time zone that deals with these concepts when converting the monotonic time into date/time field values.

Leap seconds are a special topic. In general, many systems and specifications (HTML is one such) ignore leap seconds and work in a proleptic manner (usually the error builds up the further back in time you look). This is bad for certain applications, but for most applications, since there are only 27 total leap seconds and since hardware clocks are often not that accurate, it's not specifically important. Millisecond accuracy is not usually expected for events in 1972 CE.

As you note, system time can "jump around" because of changes to the system clock. Most applications do not notice non-contiguous non-monotonic time because they are not watching the clock's value, only querying it sporadically (they also assume that the close was set correctly at some point--not always a good assumption!). Large jumps can occur, such as when the system's internet connection is down.

I kind of mixed up the discrete timelines (e.g. ghost times due to DST) with the APIs. I believe the below should be a correct representation of... time?

• TAI (International Atomic Time): Pure count of SI seconds. The canonical timeline lives here. Only here can there be no ghost times.
• UTC: Synchronized to mean solar time (Is mean solar time observed time?) by adding leap seconds. Note that leap seconds can't be computed/predicted into the future.
• Civil calendar (e.g. the Gregorian calendar): Leap days are only defined by the calendar, and handled by e.g. UTC as regular days. In other words, leap days are inserted into the calendar when mapping a day count (UTC) to years, months and days. The Gregorian calendar's leap year rules can be computed into the future (specified that UTC is used).
• Time zones: Offsets times forward and backward usually up to 12 hours. When in time zone definitions don't change, they don't add ghost times.
• DST: Jumps clocks forward and backward seasonally. Can be thought of like time zones that change definitions twice a year.

I think your notes are interesting and useful to the discussion in the document and I'll look for a way to incorporate them.

Thank you!

[axelkar]

I'd like to add that Unix time doesn't "count" (see below) leap seconds, whereas UTC does count them. Conversions from UTC to Unix time (probably somewhere in NTP or the operating system's time daemon) handle leap seconds making it so that every day in UTC is 86400 seconds of Unix time.

"counting" really is a confusing, ambiguous term. UTC literally counts leap seconds (but jumps back to systems assuming all UTC days are 86400 seconds long), Unix time counts leap seconds (AFAIK with the current behavior by repeating a second), TAI counts seconds that UTC would mark as leap seconds.