> Just store the time stamp and time zone separately and update the time stamp to reflect any changes to a time zone's offset
Thus reinventing zoned datetimes badly
> if that actually happens
It happens literally all the time, sometimes with very little heads up e.g. the decision to apply DST or not can be take mere weeks before it actually occurs[0], and something as impactful as an entire calendar day disappearing can happen with 6 months notice[1].
Thanks for this - I've learned something new today. I did not realise timezone updates were so frequent.
I do find that having the timestamp at hand makes math easier in a lot of the use cases I've come across. I wonder if there is an easy hybrid solution where you can capture timezone info, timestamp info and have it adjust without a full DB update, even if timezone offsets change. Maybe a mapping table of some kind, with versioned timezone codes.
Thus reinventing zoned datetimes badly
> if that actually happens
It happens literally all the time, sometimes with very little heads up e.g. the decision to apply DST or not can be take mere weeks before it actually occurs[0], and something as impactful as an entire calendar day disappearing can happen with 6 months notice[1].
[0] https://egyptindependent.com/egypts-hasty-goodbye-daylight-s..., https://codeofmatt.com/time-zone-chaos-inevitable-in-egypt/
[1] https://www.theguardian.com/world/2011/dec/30/samoa-loses-da...