6 ms·

How does that make sense? Unix time is basically a stopwatch that someone started a long time ago. How would a leap second matter?

koeng 5y ago
Because unix time isn't a stopwatch that someone started a long time ago. Leap seconds change unix time because unix time is tied to UTC.
- erdos4d 5y ago
  I'm not really following. How does the fact that Unix timestamps are in terms of UTC affect whether leap seconds get incorporated into the timestamp or not? Do leap seconds work differently in UTC or something?
  - growse 5y ago
    Unix timestamp assumes there are exactly 86400 seconds in a day. Or, in other words, if your timestamp is a multiple of 86400, it's midnight UTC. There are not alway 86400s in 1 day. Midnight is not a whole number of multiples of 86400 after Jan 1st 1970.
    - deleted 5y ago
      [deleted]
    - fivea 5y ago
      > There are not alway 86400s in 1 day. Midnight is not a whole number of multiples of 86400 after Jan 1st 1970. Isn't that an issue with the format you want to convert UNIX time to ? I mean, UNIX time is quite clearly and unambiguously defined as the number of seconds that passed since January 1st 1970. How are UTC's leap seconds any relevant?
      - growse 5y ago
        > I mean, UNIX time is quite clearly and unambiguously defined as the number of seconds that passed since January 1st 1970. It's not though. Unix time is not monotonic. It goes backwards sometimes.
  - zokier 5y ago
    Specifically unix timestamp is (number of days since 1970-01-01 × 86400) + (seconds since midnight). The difference arises from the fact that in utc some days are 86401 seconds long. Another way of viewing it is that unix timestamp is seconds since 1970-01-01 minus number of leap seconds that have passed.
  - voxic11 5y ago
    > If a leap second is to be inserted, then in most Unix-like systems the OS kernel just steps the time back by 1 second at the beginning of the leap second, so the last second of the UTC day is repeated and thus duplicate timestamps can occur. So certain unix timestamp can represent two different points in time, the last normal second of the day or the leap second that happened after it. This makes (certain) unix timestamps ambiguous.
  - masklinn 5y ago
    > Do leap seconds work differently in UTC or something? Leap seconds exist in UTC, that's the entire thing. A leap second getting inserted (which has always been the case so far, though it may eventually change) means a UTC day ends on 23:59:60, which as far as UTC is concerned is perfectly fine, nothing wrong with a minute having 61 seconds. UNIX time though? UNIX time is (86400 * days since epoch) + seconds since midnight. 23:59:60 is 86400, so on the last second of day X you're at 86400 * X + 86400, and on the next second (the first of day X+1) you're at 86400 * (X+1) + 0. Which is the same value. And thus one second repeats.
deleted 5y ago
[deleted]
NavinF 5y ago
Naw that would make way too much sense. Instead, unix time ticks backwards 1 second to sync up with UTC: 099.75 100.00 100.25 100.50 100.75 100.00 100.25 100.50 100.75 101.00 Maybe some day we’ll get rid of this collective brain damage: https://en.wikipedia.org/wiki/Leap_second#International_proposals_for_elimination_of_leap_seconds https://en.wikipedia.org/wiki/Leap_second#International_prop...
- thehappypm 5y ago
  Dear God.
- fivea 5y ago
  > Naw that would make way too much sense. Instead, unix time ticks backwards 1 second to sync up with UTC: Doesn't that mean that UNIX time is in fact a stopwatch, but to express it in UTC you need to factor in UTC's quirks such as its leap seconds?
  - NavinF 5y ago
    No. Like I said, that would make way too much sense. The hardware RTC on your motherboard is a stopwatch. When a leap second occurs, your system time will be set 1 second backwards which is also 1 second less than what the RTC reports. Then, the new fuckered time will be written to the RTC so it stops acting as a stopwatch and instead tracks unix time. An application that reads the system unix time 4 times a second (using a monotonic clock for the 250ms delay) and prints it will observe a negative duration in unix time as seen in my previous comment. > to express it in UTC you need to factor in UTC's quirks such as its leap seconds Oh that would make unix time so much more useful. But no, the UTC quirk is incorporated into unix time the instant a leap second happen as if some nutjob logged into all your servers and changed each clock manually.
masklinn 5y ago
UNIX time is not actually a stopwatch, it's defined as 86400 seconds per day elapsed since epoch, plus the number of seconds elapsed since the last midnight (in essence it matches UTC seconds from 1970). Thus UNIX time is at least 27 seconds late (because there have been 27 seconds since 1972).

koeng 5y ago

Because unix time isn't a stopwatch that someone started a long time ago. Leap seconds change unix time because unix time is tied to UTC.

erdos4d 5y ago
I'm not really following. How does the fact that Unix timestamps are in terms of UTC affect whether leap seconds get incorporated into the timestamp or not? Do leap seconds work differently in UTC or something?
- growse 5y ago
  Unix timestamp assumes there are exactly 86400 seconds in a day. Or, in other words, if your timestamp is a multiple of 86400, it's midnight UTC. There are not alway 86400s in 1 day. Midnight is not a whole number of multiples of 86400 after Jan 1st 1970.
  - deleted 5y ago
    [deleted]
  - fivea 5y ago
    > There are not alway 86400s in 1 day. Midnight is not a whole number of multiples of 86400 after Jan 1st 1970. Isn't that an issue with the format you want to convert UNIX time to ? I mean, UNIX time is quite clearly and unambiguously defined as the number of seconds that passed since January 1st 1970. How are UTC's leap seconds any relevant?
    - growse 5y ago
      > I mean, UNIX time is quite clearly and unambiguously defined as the number of seconds that passed since January 1st 1970. It's not though. Unix time is not monotonic. It goes backwards sometimes.
- zokier 5y ago
  Specifically unix timestamp is (number of days since 1970-01-01 × 86400) + (seconds since midnight). The difference arises from the fact that in utc some days are 86401 seconds long. Another way of viewing it is that unix timestamp is seconds since 1970-01-01 minus number of leap seconds that have passed.
- voxic11 5y ago
  > If a leap second is to be inserted, then in most Unix-like systems the OS kernel just steps the time back by 1 second at the beginning of the leap second, so the last second of the UTC day is repeated and thus duplicate timestamps can occur. So certain unix timestamp can represent two different points in time, the last normal second of the day or the leap second that happened after it. This makes (certain) unix timestamps ambiguous.
- masklinn 5y ago
  > Do leap seconds work differently in UTC or something? Leap seconds exist in UTC, that's the entire thing. A leap second getting inserted (which has always been the case so far, though it may eventually change) means a UTC day ends on 23:59:60, which as far as UTC is concerned is perfectly fine, nothing wrong with a minute having 61 seconds. UNIX time though? UNIX time is (86400 * days since epoch) + seconds since midnight. 23:59:60 is 86400, so on the last second of day X you're at 86400 * X + 86400, and on the next second (the first of day X+1) you're at 86400 * (X+1) + 0. Which is the same value. And thus one second repeats.

deleted 5y ago

[deleted]

NavinF 5y ago

Naw that would make way too much sense. Instead, unix time ticks backwards 1 second to sync up with UTC: 099.75 100.00 100.25 100.50 100.75 100.00 100.25 100.50 100.75 101.00 Maybe some day we’ll get rid of this collective brain damage: https://en.wikipedia.org/wiki/Leap_second#International_proposals_for_elimination_of_leap_seconds https://en.wikipedia.org/wiki/Leap_second#International_prop...

thehappypm 5y ago
Dear God.
fivea 5y ago
> Naw that would make way too much sense. Instead, unix time ticks backwards 1 second to sync up with UTC: Doesn't that mean that UNIX time is in fact a stopwatch, but to express it in UTC you need to factor in UTC's quirks such as its leap seconds?
- NavinF 5y ago
  No. Like I said, that would make way too much sense. The hardware RTC on your motherboard is a stopwatch. When a leap second occurs, your system time will be set 1 second backwards which is also 1 second less than what the RTC reports. Then, the new fuckered time will be written to the RTC so it stops acting as a stopwatch and instead tracks unix time. An application that reads the system unix time 4 times a second (using a monotonic clock for the 250ms delay) and prints it will observe a negative duration in unix time as seen in my previous comment. > to express it in UTC you need to factor in UTC's quirks such as its leap seconds Oh that would make unix time so much more useful. But no, the UTC quirk is incorporated into unix time the instant a leap second happen as if some nutjob logged into all your servers and changed each clock manually.

masklinn 5y ago

UNIX time is not actually a stopwatch, it's defined as 86400 seconds per day elapsed since epoch, plus the number of seconds elapsed since the last midnight (in essence it matches UTC seconds from 1970). Thus UNIX time is at least 27 seconds late (because there have been 27 seconds since 1972).