alt Hacker News> One way the website could handle this is by storing the user's exact input 2026-06-19 07:00, and also store the UTC+0 version of that datetime (if we assumed that the timezone rules won't change); this way, we can keep using the UTC+0 datetime for all logic, and we can recompute that UTC+0 datetime once we detect that the time rules for that timezone have changed.
Well, how do we know what timezone is "2026-06-19 07:00" in, to be able to know that the time rules for that timezone have changed, if we do not store the timezone?
Additionally, how do we really "detect that the time rules for that timezone have changed"? We can stay informed, sure, but is there a way to automate this?
> Well, how do we know what timezone is "2026-06-19 07:00" in, to be able to know that the time rules for that timezone have changed, if we do not store the timezone?
The website uses their system timezone America/Los_Angeles. It would be better to store that as well, but it's probably not much of an issue if the website is dedicated to meetings in that specific locale.
> Additionally, how do we really "detect that the time rules for that timezone have changed"? We can stay informed, sure, but is there a way to automate this?
My first attempt would be to diff the data between versions. If a diff of 2025b against 2025a has added/removed lines which include America/Los_Angeles, you recompute the timestamps. This, of course, requires that the library support multiple timezone database versions at once.