Worked on a project where devices just magically froze, but only during the month of February!
Turned out the people who had written the firmware had decided to do their own time math to save space and had put in an exception in the code for leap year values. Except instead of February 29th, it kicked in for the whole month. And the math was wrong so you ended up with negative values.
The product was due for launch in March of that year and was headed to manufacturing. It was by sheer luck that someone ran a test on February 1st and caught the problem.
Don’t mess with time in code, kids.
Embedded portable device with a teeny ARM processor. Sadly, no room for linux anything or even an RTC. Every time it connected to a phone, the phone would set its clock so the timestamps were somewhat close to being accurate.
However, if you swapped out the AAA battery and DIDN’T connect it to the phone at least once, all your subsequent readings would go back to zero epoch and would be forgotten 🤷🏻♂️
Good times.
Some absolute and utter legend of a man made a Unix kernel for the fucking ZILOG Z80, you have no excuses
(It’s called UZI and it’s written in K&R C for some obscure CP/M compiler)
too bad unix time only has 14 years of life left in it.
Edit: this only applies to 32 bit Unix time. The 64 bit lifespan is a little longer, at 584 billion years. Whoops lol.
Unix time.
Unix time doesn’t help with timezones… It’s always in UTC.
Unix timestamps also get a bit weird because of leap seconds. Unix timestamps have no support for leap seconds (the POSIX spec says a Unix day is always exactly 86400 seconds), so they’re usually implemented by repeating the same timestamp twice. This means that the timestamp is ambiguous for that repeated second - one timestamp actually refers to two different moments in time. To quote the example from Wikipedia:
Unix time numbers are repeated in the second immediately following a positive leap second. The Unix time number 1483142400 is thus ambiguous: it can refer either to start of the leap second (2016-12-31 23:59:60) or the end of it, one second later (2017-01-01 00:00:00). In the theoretical case when a negative leap second occurs, no ambiguity is caused, but instead there is a range of Unix time numbers that do not refer to any point in UTC time at all.
Some systems instead spread a positive leap second across the entire day (making each second a very very tiny bit longer) but technically this violates POSIX since it’s modifying the length of a second.
Aren’t timestamps fun?
Luckily, the standards body that deals with leap seconds has said they’ll be discontinued by 2035, so at least it’s one less thing that developers dealing with timestamps will have to worry about.
Don’t try to write your own date/time code. Just don’t. Use something built by someone else.
Luckily, the standards body that deals with leap seconds has said they’ll be discontinued by 2035
Did they figure out a way of making the earth spin more reliably per how the humans want it to?
Unix time doesn’t help with timezones… It’s always in UTC.
Unix timestamp is always in UTC which is why it’s helpful. It’s seconds since Jan 1st 1970 UTC. Libraries let you specify timezone usually if you need to convert from/to a human readable string.
Don’t try to write your own date/time code. Just don’t. Use something built by someone else.
…yes that’s why UNIX timestamps are helpful, because it’s a constant standard across all the libraries.
Some systems instead spread a positive leap second across the entire day (making each second a very very tiny bit longer) but technically this violates POSIX since it’s modifying the length of a second.
Then that system should be trashed.
