4 ms·
Standard PSA: Do note that storing future times only in UTC can lose important information for almost everybody at some point. When a country changes its daylig
by ghusbands 3y ago
Standard PSA: Do note that storing future times only in UTC can lose important information for almost everybody at some point. When a country changes its daylight savings time dates (as happens regularly and has happened before for the US) or decides to stay in daylight savings forever (as the EU and US are both proposing), any future events stored as UTC may then be at an incorrect local time.
The safest format for a stored future timestamp is a local time, an IANA timezone name, and, if you need it for efficiency, a derived UTC time. But you need to rederive the UTC time whenever the timezone database changes (or whenever the related entity/user changes their timezone), or it may become incorrect, as above.
- rottencupcakes 3y agoIf you're worried about the future timestamp being at a specific local time (say 10 AM on a future date), it's actually better to store a naive time and a location than the IANA timezone name. Then, if a state decides to stop doing DST, or any other funkiness like that, you can still get the time right.
- codetrotter 3y agoWhat if my country splits itself in two, and the location “Oslo/Norway” that used to describe my time zone no longer describes the place I live. And they change the time zone offset to be one hour off from what it used to be for Oslo/Norway but in the place I live the time zone offset remains as it was before the split?
- aidenn0 3y agoDon't use Oslo/Norway if you're in e.g. Trondheim; store Trondheim/Norway. I should note that it is not possible to make a database of geolocation->UTC offset that is legal in all countries, since there are countries with disputed borders, some of which care very much that no software imply the "wrong" border.
- codetrotter 3y agoOslo/Norway is the name that common time zone databases use for all of Norway.
- aidenn0 3y agoComment you originally responded to suggested: > If you're worried about the future timestamp being at a specific local time (say 10 AM on a future date), it's actually better to store a naive time and a location than the IANA timezone name. Europe/Oslo would be the IANA name for mainland Norway (Svalbard and Jan Mayen are in different IANA regions). If you're meeting somewhere at a specific time, you might as well specify that place really precisely (Maybe: Nidaros Cathedral, Trondheim, Norway) and then use that place to infer the proper UTC offset when the date approaches. There's no perfect solution as landmarks, names, &c. can all change.
- codetrotter 3y ago> Europe/Oslo Sorry yeah, this is the one I was thinking of when I said Oslo/Norway. Agree with your other points as well. I guess to increase the long term robustness one could record some additional data: GPS coordinates for the intended event GNSS coordinates using another system such as BDS or GLONASS for the intended event The current time with time zone at the time when the record was created The IANA name of the location where the record was created
- deleted 3y ago[deleted]