If you’re not using tz_database or equivalents for literally all date-time logic, if 24 or 60*60 are constants defined in your project… you’re doing it fucking wrong. I don’t know how many times we need to break out the idiot club, but date, time and timezones are extremely complicated - unless your business is primarily concerned with them you must use a library or service.
From my very basic understanding, yeah that’s basically what it does. However it accounts for a whole lot more into adding or subtracting from UTC. Timezones aren’t absolute, they’re political. Timezones have weird rules, and history that needs to be somehow expressed in the code to get the right time. That’s what’s sets tz_database apart from just looking at a map and saying it’s +7 UTC.
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.
If you’re not using tz_database or equivalents for literally all date-time logic, if 24 or 60*60 are constants defined in your project… you’re doing it fucking wrong. I don’t know how many times we need to break out the idiot club, but date, time and timezones are extremely complicated - unless your business is primarily concerned with them you must use a library or service.
Do Not Reinvent This Wheel
What does tz_database do? Wikipedia makes it seem like it basically converts a pair (geocoordinatr, utc time) to local time
From my very basic understanding, yeah that’s basically what it does. However it accounts for a whole lot more into adding or subtracting from UTC. Timezones aren’t absolute, they’re political. Timezones have weird rules, and history that needs to be somehow expressed in the code to get the right time. That’s what’s sets tz_database apart from just looking at a map and saying it’s +7 UTC.
So it updates now and then with new rules, and it keeps historical rules for past dates?
I think so. Like I said, I have a very basic understanding of it. There are definitely a lot of people who know more about this than I do.
What is tz-database equivalent in batch language ?
I once worked with a framework that was incompatible with libraries. All of them.
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.