5 ms·
about "never not UTC" (but otherwise unrelated to the OP): There was an article recently, describing a very important, and also very common, "exception": If y
by eurg 7y ago
about "never not UTC" (but otherwise unrelated to the OP):
There was an article recently, describing a very important, and also very common, "exception":
If you want to schedule/synchronize real-world appointments/events, you need both the _local time_ and the political zone, like 2018-12-11 9am at Europe/London.
The reason is that between time of entry and time of event, the defined timezone for that area may change. As a result, your previously translated appointment would not match up the local time.
Which is bad, because humans, when meeting, or events, when being announced, announce the local time. Not UTC. And they stick to the local time.
- pmontra 7y agoI remember that post. It's not a remote chance. Every EU country will have to choose whether to stay forever in DST or forever in standard time, probably in 2021. Some of them will likely change time zone as a result.
- dagss 7y agoI know and that is why I said "as opposed to user entry"
- mixmastamyk 7y agoInteresting. Having trouble with one minor point. When a local datetime (in a known timezone) is converted to UTC, won't it know the proper DST setting for that datetime? Seems like it should still get the right answer, with the even smaller exception that a law might be passed to change DST in the meantime.