You're viewing a single thread.
Then there's my code, which didn't even survive the time change.
In every project I've ever worked on, there's been somebody who must have been like, "HurDur Storing timestamps in UTC is for losers. Nyeaahh!"
And if I ever find that person, I'm going to get one of those foam pool noodles, and whack him/her over the head with it until I've successfully vented all my frustrations.
I just use a float between 0 and 1 with 0 being 1970 and 1 being the predicted heat death of the universe.
The only time using UTC breaks down is when any sort of time change gets involved.
If I say I want a reminder at 9am six months from now and you store that as UTC, a day light savings change will mean I get my reminder an hour early or late depending on where in the world I am
But wouldn't you calculate the time in the future in the right time zone and then store it back as UTC?
It depends on the application.
I don't remember all the specifics but this is the blog post I refer to when this topic comes up
https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/
So TL;DR: there might be unexpected time zone rule changes in the future. The solution presented in the article is to store both UTC and local time, so the application can easily adjust itself if such change happens.
Your code made it to the time change!!?
Same... The change from 12 to 1