> We know that some character must be smaller than 9, for example, we cannot have more than 59 seconds and never 60 seconds, in the time stamp string.
This is how you get leap seconds bugs?
This is how you get leap seconds bugs?
UNIX time ignores leap seconds.
I.e. it's the number of seconds ignoring leap seconds since 1970.
And apparently these strings don't have second 60.
Works for me.
Side note but I always found this phrasing to be incredibly confusing (hence the need for the "i.e."...); it's the exact opposite of what I would think it means to "ignore" leap seconds. Ignoring something means you don't change your behavior when that something happens. But when leap seconds happen, the epoch timestamp halts its counting. That's not ignoring leap seconds -- that's actively countering the leap seconds!
Normally, UNIX time goes up by one each second.
Unless, it's a leap second, in which case UNIX time does nothing.
Example: You're driving your car when pedestrians appear in front of you. What does "ignoring" them constitute? Stopping the car, or running into them at the previous speed?
At the point they needed to be inserted, Unix systems carry on counting seconds as units of time as they pass, "ignoring" the need to add 1 for the purposes of accounting.
unix systems essentially will roll back clocks during leap seconds. here is handy dandy table as an example:
Time tv_sec tv_usec
2015-06-30T23:59:58.9Z 1435708798 900000
2015-06-30T23:59:59.0Z 1435708799 0
2015-06-30T23:59:59.1Z 1435708799 100000
... ... ...
2015-06-30T23:59:59.9Z 1435708799 900000
2015-06-30T23:59:60.0Z 1435708799 0
2015-06-30T23:59:60.1Z 1435708799 100000
... ... ...
2015-06-30T23:59:60.9Z 1435708799 900000
2015-07-01T00:00:00.0Z 1435708800 0
2015-07-01T00:00:00.1Z 1435708800 100000
... ... ...
But when I count people passing me, I press my clicker each time to count them. Except once in a while I don't do anything, i.e. ignore them.
Doing anything else means handling them by adding custom behavior.
You can make a pretty good argument that "every day is 86400 seconds" is ignoring leap seconds. And that's what "Unix time" does.
Though you can also make a good argument that "seconds since 1970, no idea what a 'day' is" ignores leap seconds.
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...
If you're subtracting Unix timestamps to get durations you may have bugs, but those bugs might align better to your user's expectations anyway.
Unix time is seconds since 1970... If you convert between time formats you MAY loose information. That has nothing to do with unix time.
In this case, without leap seconds, you'd have still lost the precision, but you wouldn't have actually violated causality. Winding back during a leap second makes it so that a timestamp that's > 1 second later in real time still ends up being ordered as strictly before the earlier time. That's a bug, regardless of how you slice it.
Now this can be partially avoided by saturating the subtraction at the boundary rather than winding it back, and I'm not sure how many implementations do this. That seems better, but it's still surprising (and thus bug-prone) given the input and output representation otherwise appear to have sufficient precision.
If converting things from one system to another means two very close events get the same timestamp? Eh, that can happen in many ways with many systems. That's not bugginess.
This is unfortunately common misconception. Unix time in reality is seconds since epoch minus the number of leap seconds
I it just a guy hwo started counting at 1970
UTC: 58, 59, 60, 00, 01
UNIX: 58, 59, 00, 00, 01
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.
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.
This is plain false. For example 1435708799 corresponds to both 2015-06-30T23:59:59Z and 2015-06-30T23:59:60Z
https://elixir.bootlin.com/linux/v6.4.1/source/kernel/time/n...
sure leap smearing could be considered compatible with posix in the sense that posix does afaik not require any level of accuracy from clocks, so even something silly like xkcd 2266 could be considered posix compatible https://xkcd.com/2266/
This seems like a major overcorrection. It's equivalent to saying "you can't know anything" "no one is qualified to do anything"
You really have to consider the downsides. In cryptography, "don't roll you own crypto" is the maxim because the downside is pretty bad. Make sure you're an expert before writing crypto.
What's the downside to mis-parsing leap seconds? Maybe a 500 on a super rare request? Then they patch it and it's fine? Most computers are off by more than 1 second anyway.
I think this mindset comes from developers looking into some field and realizing it's super deep ("Did you know there are missing dates in the gregorian calendar if you go back hundreds of years? Your time library is incorrect if it doesn't handle these cases!"). And sure, most things aren't completely correct, but you have to consider what the downside is to being slightly wrong. Maybe it'll be wrong in cases that will never actually happen in practice.
How is anything going to be made then ?
Also, the author isn't just anybody and has created stuff that you've most likely interacted with. If almost nobody should "roll his own", he's one of those who should.