eligrubbs
commented
10 hours ago The recommendation is to store "clock time" and a timezone. Since timezone ranges change, storing UTC only might make a future date appear earlier or later than it would feel. In the comment, the guy shared: "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 problem would be solved if someone stored 2006-11-01 8:00:00, and 2007-11-01 8:00:00 with "America/Boston" or whatever as the timezone. That way, when the definition of when daylight savings time starts changes, the correct time of day for the 8am event would be preserved for someone looking at it at that time. If the UTC was the only thing stored, the same UTC would have been stored, so when the definition changed, the event you had planned for would appear to have happened at 7am if you checked your calendar on Nov. 1 2007!
Requirements: Some way to store, unambiguously, the dates that things happen past, present and future. I thought storing "Timezone aware" datetimes was ok in the database, but SQLite does't support datetimes so I had to think about it.
This guy: https://dev.to/corykeane/3-simple-rules-for-effectively-handling-dates-and-timezones-1pe0#comment-f5mo says that future dates need special consideration because things change.
Either way, something must change as all advice says to store datetimes in UTC, and either convert to local time in the frontend if dates translate that way, or store extra info of a sort I haven't quiet grasped (letters like EST or America/New York).