IMO it’s not that complicated, most time data still stores time as the number of seconds since Jan 1 1970. As long as people are interpreting UNIX Time correctly then there should be no issues no matter how you divide that up.
Unix time is not the number of seconds since 1/1/1970 this is a common misconception. It’s the number of days since 1/1/1970 times 86400 plus the number of seconds elapsed in the current day. These two systems of measurement are almost always the same, yay! But… not always.
This is the nichest of niche edgecases so don’t feel bad about being unaware of it. It’s extremely arcane knowledge that developers shouldn’t generally bother learning… but it’s an excellent example of my initial statement. The maintainers of tz_database know this shit and plenty of other obscure bullshit they know it and build it into their library of functions so that we don’t need to worry about it. And that is an excellent reason to not reinvent the wheel.
IMO it’s not that complicated, most time data still stores time as the number of seconds since Jan 1 1970. As long as people are interpreting UNIX Time correctly then there should be no issues no matter how you divide that up.
Unix time is not the number of seconds since 1/1/1970 this is a common misconception. It’s the number of days since 1/1/1970 times 86400 plus the number of seconds elapsed in the current day. These two systems of measurement are almost always the same, yay! But… not always.
Unix time will occasionally double count the same seconds when leap seconds are involved. As an example please enjoy an outage in 2012 caused by this very issue: https://www.wired.com/2012/07/leap-second-glitch-explained/
Date and time are more complicated than we give it credit for. You can use Unix time and be nearly always correct but you are still wrong.
That is news to me, and it very clearly would cause problems with the 26 hour day as well.
This is the nichest of niche edgecases so don’t feel bad about being unaware of it. It’s extremely arcane knowledge that developers shouldn’t generally bother learning… but it’s an excellent example of my initial statement. The maintainers of tz_database know this shit and plenty of other obscure bullshit they know it and build it into their library of functions so that we don’t need to worry about it. And that is an excellent reason to not reinvent the wheel.