2 ms·
> Each Unix timestamp corresponds to one unique point in time That depends. 30th June 2015 23:59:59 has the timestamp 1435708799. 1st July 2015 00:00:00 has th
by wongarsu 3y ago
> Each Unix timestamp corresponds to one unique point in time
That depends. 30th June 2015 23:59:59 has the timestamp 1435708799. 1st July 2015 00:00:00 has the timestamp 1435708800. But what about the leap second that happened between those two seconds? I think most people would claim it also has timestamp 1435708799. but then "Each Unix timestamp corresponds to one unique point in time" isn't true, because 1435708799 now corresponds to two different points in time (30th June 2015 23:59:59 and 30th June 2015 23:59:60). Saying there is a unique mapping from unix timestamp to time would only be true if you either say that 30th June 2015 23:59:60 has no unix timestamp (which isn't a valid return value of any time API I've seen) or if you smear time.
- jodrellblank 3y agoIt still wouldn't be true because there are points in time smaller than a second.
- morelisp 3y agoNo, I didn't say it was a bijective mapping. (Although with smearing, it still can be.)
- morelisp 3y ago> 30th June 2015 23:59:60 has no unix timestamp (which isn't a valid return value of any time API I've seen) https://go.dev/play/p/I8GcKBoAVXi https://go.dev/play/p/I8GcKBoAVXi
- bobbylarrybobby 3y agoWell, all time stamps are rounded or floored to the nearest second (or millisecond, or micro, or...) because you only have a finite amount of space to store them — you always have infinitely many time stamps mapping to each Unix second. This means you can just adjust the mapping around the leap second. A naive implementation might have those two real-life seconds tick twice as fast to take only one Unix second. Or you could have the whole day’s seconds tick 86401/86400 times as fast, etc. In terms of the mapping from continuous time to discrete time, this is just as fine as the non-leap-second case.