5 ms·

I don't understand this one: > If I wait exactly one second, Unix time advances by exactly one second How does UTC jumping around affect this? If a leap secon

I don't understand this one: > If I wait exactly one second, Unix time advances by exactly one second How does UTC jumping around affect this? If a leap second is removed it doesn't mean you've waited 0 seconds. I feel like this is wrong too: > If there’s a leap second in a day, Unix time either repeats or omits a second as appropriate to make them match. It's not Unix time doing that. It's UTC.

seaish 7y ago
Unix time is based on a hard calculation of UTC seconds, minutes, hours, days, and years. So UTC jumping causes a discontinuity in Unix time. Im pretty sure the second graph is mislabeled (the UTC second after 23:59:60 should be 00:00:00), but Unix time takes 23:59:60 to mean the same as 00:00:00. So 23:59:60.5 is also the same as 00:00:00.5, and so on. If you parsed the Unix time into a readable timestamp, it would tell you it's the first second of the next day for two seconds.
Groxx 7y ago
UTC jumping around affects it if you're basing your time-elapsed measure by checking "time.now() - previouslySavedTime". That can give you a negative value, if e.g. your 1/2-second elapsed time crossed a leap second.
jlg23 7y ago
> How does UTC jumping around affect this? If a leap second is removed it doesn't mean you've waited 0 seconds The OP did not make this claim. He said that waiting 1s does not necessarily increase the Unix time by one second - not the other way around. Or how my highschool math teacher put it: Every time it rains, the street gets wet. But not every time the street is wet, it rained - maybe my dog just took a leak....
masklinn 7y ago
> How does UTC jumping around affect this? If a leap second is removed it doesn't mean you've waited 0 seconds. No, but it means UNIX time does not advance by exactly one second per elapsed second. Instead it advances by either 0 or 2. > It's not Unix time doing that. It's UTC. It's also unix time. unix time is (86400 * days_since_epoch + seconds_since_midnight). A leap second means a day is not 86400 seconds, and thus you'll either get a skip or a repeat on midnight rollover.

seaish 7y ago

Unix time is based on a hard calculation of UTC seconds, minutes, hours, days, and years. So UTC jumping causes a discontinuity in Unix time. Im pretty sure the second graph is mislabeled (the UTC second after 23:59:60 should be 00:00:00), but Unix time takes 23:59:60 to mean the same as 00:00:00. So 23:59:60.5 is also the same as 00:00:00.5, and so on. If you parsed the Unix time into a readable timestamp, it would tell you it's the first second of the next day for two seconds.

Groxx 7y ago

UTC jumping around affects it if you're basing your time-elapsed measure by checking "time.now() - previouslySavedTime". That can give you a negative value, if e.g. your 1/2-second elapsed time crossed a leap second.

jlg23 7y ago

> How does UTC jumping around affect this? If a leap second is removed it doesn't mean you've waited 0 seconds The OP did not make this claim. He said that waiting 1s does not necessarily increase the Unix time by one second - not the other way around. Or how my highschool math teacher put it: Every time it rains, the street gets wet. But not every time the street is wet, it rained - maybe my dog just took a leak....

masklinn 7y ago

> How does UTC jumping around affect this? If a leap second is removed it doesn't mean you've waited 0 seconds. No, but it means UNIX time does not advance by exactly one second per elapsed second. Instead it advances by either 0 or 2. > It's not Unix time doing that. It's UTC. It's also unix time. unix time is (86400 * days_since_epoch + seconds_since_midnight). A leap second means a day is not 86400 seconds, and thus you'll either get a skip or a repeat on midnight rollover.