To be fair, returning the actual timezone (as defined by tz.db) is useful if you don’t just want the current time since you’ll be able to take DST into account. Not sure how Vienna is -8 though, it should be +1 (or 2 depending on DST).
Your comment is a full throated endorsement of just working in UTC up until the presentation layer. Whether you intended that or not is another question.
To be clear I believe it makes sense to do a lot of things in UTC, but future events should almost always be local time + timezone to make scheduling predictable and consistent to humans.
I don’t see how your way is any more predictable or consistent than using UTC. What even is “local time”? Are you assuming they haven’t changed timezone since they created the data? Say…DST happened, or they drove over a border…?
Storing and manipulating in UTC is the most predictable and consistent because it is universal and unchanging. You only need to worry about “local time” at the point of displaying it.
We have slackbots that post, for instance, who has vecation every day. Because it is configured to post this using UTC, the time of day this is posted changes twice a year.
I might have a recurring appointment for lunch in my calendar every day at noon. Now DST happened, so I have to wait until one to eat. That is inconsistent to me.
Timezones change. If I have to go to the theatre on half a year at 18:00, I don’t want to be there at 19:00 because someone decided local time would be better if we moved it an hour. The show time certainly won’t be moved.
What is local time? It’s spacetime. When did it happen and if relevant (eg. a photo) what was the offset (because I would like to know the time of day)? When will it happen, and where? Online meetings across timezones are tricky, of course, but excluding the timezone won’t improve that.
Notice the common problem here? DST. Get rid of it and you get rid of the inconsistency that happens parts of the year, and you reduce fatality rates that resulted from moving time twice a year.
So just for additional context:
This meme was brought to you by the following API response scheme:
{ "time": "2007-12-24 18:12", "servertimezone": "Europe/Vienna", "timezoneoffset": -8 }when it could have just been
{ "date": "2007-12-24T18:21:00-07:00" }To be fair, returning the actual timezone (as defined by tz.db) is useful if you don’t just want the current time since you’ll be able to take DST into account. Not sure how Vienna is -8 though, it should be +1 (or 2 depending on DST).
Your comment is a full throated endorsement of just working in UTC up until the presentation layer. Whether you intended that or not is another question.
It is? Without even mentioning it?
To be clear I believe it makes sense to do a lot of things in UTC, but future events should almost always be local time + timezone to make scheduling predictable and consistent to humans.
Yes. Not intentionally of course. But yes.
I don’t see how your way is any more predictable or consistent than using UTC. What even is “local time”? Are you assuming they haven’t changed timezone since they created the data? Say…DST happened, or they drove over a border…?
Storing and manipulating in UTC is the most predictable and consistent because it is universal and unchanging. You only need to worry about “local time” at the point of displaying it.
We have slackbots that post, for instance, who has vecation every day. Because it is configured to post this using UTC, the time of day this is posted changes twice a year.
I might have a recurring appointment for lunch in my calendar every day at noon. Now DST happened, so I have to wait until one to eat. That is inconsistent to me.
Timezones change. If I have to go to the theatre on half a year at 18:00, I don’t want to be there at 19:00 because someone decided local time would be better if we moved it an hour. The show time certainly won’t be moved.
What is local time? It’s spacetime. When did it happen and if relevant (eg. a photo) what was the offset (because I would like to know the time of day)? When will it happen, and where? Online meetings across timezones are tricky, of course, but excluding the timezone won’t improve that.
Notice the common problem here? DST. Get rid of it and you get rid of the inconsistency that happens parts of the year, and you reduce fatality rates that resulted from moving time twice a year.
I agree! Can we also get rid of politicians, mosquitoes and people who use their phone at the cinema?
Just for further clarification, the API works like this:
timeis the local (client) time (in this case UTC-7)servertimezoneis the time zone where the server is locatedtimezoneoffsetis the offset of the local time relative to the servertimezone (offset from the servers PoV)To get the UTC date you have to do something like this:
time.minusHours(timezoneoffset).atZone(servertimezone).toUTC()It should’ve been unix timestamp