5 ms·

Leap seconds affect Unix time too, because leap seconds are excluded from "number of seconds since Unix epoch". You can't measure the length of time intervals s

Leap seconds affect Unix time too, because leap seconds are excluded from "number of seconds since Unix epoch". You can't measure the length of time intervals spanning leap seconds with simple subtraction.

Misdicorl 7y ago
Are they truly? There must be a good reason but I can't fathom what it could be
- heartbeats 7y ago
  Because otherwise you would get annoying off-by-27 errors whenever you did time() % 60. https://en.wikipedia.org/wiki/Leap_second#Binary_representation_of_the_leap_second https://en.wikipedia.org/wiki/Leap_second#Binary_representat...
- GolDDranks 7y ago
  That good reason is that there is no general "formula" for leap seconds, unlike for leap years, they have to be looked up. So you can't do "offline" date calculations if they included leap seconds. I think that UNIX time stamps are generally a very good approximation, and if you are comparing long enough time intervals for the error to get over one second, and/or that error to matter, you are doing something wrong anyway. For exact time interval measurements that you have to get exactly right, don't use UNIX time stamps.
  - Misdicorl 7y ago
    The lookup database is incredibly small and updated very infrequently. Certainly smaller and less frequent than tzinfo which is also included in the kernel
    - labawi 7y ago
      AFAICT leap seconds are announced about 6 months in advance (January/June). How would you process times that are to occur after a leap second that may or may not be? You could store something as '2022-02-02 02:22:22 UTC', but try storing it as seconds since epoch, if you don't know if there will be leap seconds. Not to mention software that may be years or decades old.
lmm 7y ago
> Leap seconds affect Unix time too, because leap seconds are excluded from "number of seconds since Unix epoch". They are excluded from "unix timestamps". They would still be part of the number of seconds since Unix epoch.
- labawi 7y ago
  What does that mean and how would that work? AFAIK, unix time skips a beat or repeats itself to remain in alignment with UTC, and just keeps chugging along.
  - lmm 7y ago
    "Number of seconds since the unix epoch" describes a physical measurement (that can be related directly to TAI) that would not be affected by leap seconds. You could store that number to allow you to recover TAI timestamps (I'm not aware of any OS that does this, but there's no reason it wouldn't be possible). Unix time does indeed repeat itself so as to remain in alignment with UTC. But unix time is not the number of seconds since the unix epoch.
    - labawi 7y ago
      Thank you, I think I understand, but disagree on terminology. Leap seconds are not excluded from number of seconds since Unix epoch, interpreted on a physical, TAI, UTC, typical local time scales. However, they are indeed excluded from "number of seconds since Unix epoch", when interpreted in unix time. In unix time, those seconds simply don't exists (never happened) and the events of those seconds are smooshed sometime. Unix time representation forms a (quirky) timescale. I'll quote a few excerpts from 'date' man page of linux, openbsd and for gettimeofday: Convert seconds since the epoch (1970-01-01 UTC) to a date Print out (in specified format) the date and time represented by seconds from the Epoch. The time is expressed in seconds and microseconds since midnight (0 hour), January 1, 1970
      - lmm 7y ago
        Hmm. The first definition I saw of "unix timestamp" explicitly defined it as "86400 * number of days since 1970-01-01 + number of seconds since midnight", which I thought was clever and clear, but I can't find it now. Having looked up the POSIX standard at https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16 https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1... it seems you're right and I'm wrong; they define "Seconds Since the Epoch" as "A value that approximates the number of seconds that have elapsed since the Epoch...". In my view this is an extremely poor choice of terminology, because "seconds since the epoch" should have its plain English meaning of the number of SI seconds that have passed since that event; defining some "second" that is almost, but not quite, an SI second seems like a recipe for disaster.

Misdicorl 7y ago

Are they truly? There must be a good reason but I can't fathom what it could be

heartbeats 7y ago
Because otherwise you would get annoying off-by-27 errors whenever you did time() % 60. https://en.wikipedia.org/wiki/Leap_second#Binary_representation_of_the_leap_second https://en.wikipedia.org/wiki/Leap_second#Binary_representat...
GolDDranks 7y ago
That good reason is that there is no general "formula" for leap seconds, unlike for leap years, they have to be looked up. So you can't do "offline" date calculations if they included leap seconds. I think that UNIX time stamps are generally a very good approximation, and if you are comparing long enough time intervals for the error to get over one second, and/or that error to matter, you are doing something wrong anyway. For exact time interval measurements that you have to get exactly right, don't use UNIX time stamps.
- Misdicorl 7y ago
  The lookup database is incredibly small and updated very infrequently. Certainly smaller and less frequent than tzinfo which is also included in the kernel
  - labawi 7y ago
    AFAICT leap seconds are announced about 6 months in advance (January/June). How would you process times that are to occur after a leap second that may or may not be? You could store something as '2022-02-02 02:22:22 UTC', but try storing it as seconds since epoch, if you don't know if there will be leap seconds. Not to mention software that may be years or decades old.

lmm 7y ago

> Leap seconds affect Unix time too, because leap seconds are excluded from "number of seconds since Unix epoch". They are excluded from "unix timestamps". They would still be part of the number of seconds since Unix epoch.

labawi 7y ago
What does that mean and how would that work? AFAIK, unix time skips a beat or repeats itself to remain in alignment with UTC, and just keeps chugging along.
- lmm 7y ago
  "Number of seconds since the unix epoch" describes a physical measurement (that can be related directly to TAI) that would not be affected by leap seconds. You could store that number to allow you to recover TAI timestamps (I'm not aware of any OS that does this, but there's no reason it wouldn't be possible). Unix time does indeed repeat itself so as to remain in alignment with UTC. But unix time is not the number of seconds since the unix epoch.
  - labawi 7y ago
    Thank you, I think I understand, but disagree on terminology. Leap seconds are not excluded from number of seconds since Unix epoch, interpreted on a physical, TAI, UTC, typical local time scales. However, they are indeed excluded from "number of seconds since Unix epoch", when interpreted in unix time. In unix time, those seconds simply don't exists (never happened) and the events of those seconds are smooshed sometime. Unix time representation forms a (quirky) timescale. I'll quote a few excerpts from 'date' man page of linux, openbsd and for gettimeofday: Convert seconds since the epoch (1970-01-01 UTC) to a date Print out (in specified format) the date and time represented by seconds from the Epoch. The time is expressed in seconds and microseconds since midnight (0 hour), January 1, 1970
    - lmm 7y ago
      Hmm. The first definition I saw of "unix timestamp" explicitly defined it as "86400 * number of days since 1970-01-01 + number of seconds since midnight", which I thought was clever and clear, but I can't find it now. Having looked up the POSIX standard at https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16 https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1... it seems you're right and I'm wrong; they define "Seconds Since the Epoch" as "A value that approximates the number of seconds that have elapsed since the Epoch...". In my view this is an extremely poor choice of terminology, because "seconds since the epoch" should have its plain English meaning of the number of SI seconds that have passed since that event; defining some "second" that is almost, but not quite, an SI second seems like a recipe for disaster.