Storing datetimes in UTC is good practice, unless you have to store future datetimes, in which case you need to save the "clock time" and the time zone, in case that time zone changes DST in the future. Kind of edge-casey but countries change their DST dates all the time, and sometimes drop in/out completely.
Asking as an Ops engineer, this sounds relevant and something to have in the "nice to know" mental-stack-but what would be an example edge-case you speak of here?
Man, I wrote some massive emails trying to work through this once upon a time, but here's a pretty simple way to think about it.
In 2005 the US moved the end of DST from the last Sunday in October to the first Sunday in November starting in 2007. So the UTC datetime for 8am November 1 in Boston in 2006 was 2006-11-01T13:00:00+00:00, but 2007-11-01T12:00:00+00:00 the following year. This is never a problem for historical dates because your TZ library knows what the UTC/DST offset was for any time zone on any date. What it does not know is what the UTC/DST offset will definitely be on future dates.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Storing datetimes in UTC is good practice, unless you have to store future datetimes, in which case you need to save the "clock time" and the time zone, in case that time zone changes DST in the future. Kind of edge-casey but countries change their DST dates all the time, and sometimes drop in/out completely.
Asking as an Ops engineer, this sounds relevant and something to have in the "nice to know" mental-stack-but what would be an example edge-case you speak of here?
Man, I wrote some massive emails trying to work through this once upon a time, but here's a pretty simple way to think about it.
In 2005 the US moved the end of DST from the last Sunday in October to the first Sunday in November starting in 2007. So the UTC datetime for 8am November 1 in Boston in 2006 was 2006-11-01T13:00:00+00:00, but 2007-11-01T12:00:00+00:00 the following year. This is never a problem for historical dates because your TZ library knows what the UTC/DST offset was for any time zone on any date. What it does not know is what the UTC/DST offset will definitely be on future dates.