If everyone had the same clock time, we would need to know when it was morning, midday and evening for people in other locations. Scheduling stuff between locations would still suck, but it would suck differently.
Maybe this solar device could have a marker that would cast a shadow on some sort of measuring device. That device could document the sun’s relative position for that region of the earth.
Then, when we schedule a meeting between regions, people could share their relative shadow positions from their measuring devices.
Yeah but it could be improved by not using arbitrary country-decided timezones and instead simply listing "diurnal time", basically. And then clocks could get normalized as always showing UTC nearby, too. For communication.
That's not reasonable at all. The purpose of time is to help organize society across distance. The purpose of states/countries/administrative districts is to help organize society within a similar geographical region. It is entirely reasonable for timezones to conform to political boundaries.
I don't know about that, it seems like one of the things that makes the world simple for programmers and complex for everyone else. It doesn't allow for large countries to split along sensible political boundaries. So if one boundary slices through the middle of New York City, too bad. Moving boundaries to instead be at state/province/etc boundaries or in the middle of nowhere like we usually see now seems more sensible.
Even worse. Daylight savings creators. I work in manufacturing and we literally stut down the production line for an hour during the "fall back" and "spring ahead" so we can manually change the time on every computer.
For quality control it did. The real concern is people messing up time. If there was a quality complaint we wanted it to be easy for people to go back thru production data. A lot of the people operating the machinery and performing quality checks at our facility are not well educated, and the need is there to make investigating quality tasks/entering quality data very easy.
Time is possibly one of the hardest things to handle properly for a coder. There's plenty of hard problems (network loss, 3 phase commits, etc), but time stand out as really annoying.
Another one is colors. All it takes is one library to encode colors in a weird way and then mapping them between libraries is a mess.
Store times in UTC, convert in UI to locale's timezone with one of any of the millions of timezone libraries. If you're storing in local time, you're gonna have a bad time.
But for time of day, use local time and store separate column with the timezone name. Don't use timezone offsets since that doesn't work with DST. You're better off with something like America/New_York because God knows what 2030 will look like.
And if timezone are abolished, or DST, that's even more reason to store the timezone name.
It depends. If something needs to happen in local time (like, always at the same time regardless of daylights savings for example) you should be storing times in local timezone