Handling Time Zone in JavaScript (2019)(medium.com)
medium.com
Handling Time Zone in JavaScript (2019)
https://medium.com/@toastui/handling-time-zone-in-javascript-547e67aa842d
6 comments
> “Just use UTC” is a good half assed approach
I think the correct approach is that "always store times in UTC". Then you adjust for wall-clock time on the client.
I think the correct approach is that "always store times in UTC". Then you adjust for wall-clock time on the client.
Of course there are battle stories, like if a territory announces that from a particular date in the future, they will use a new timezone (with a different offset) - e.g. when the US government changed the start and end of DST during the W. Bush presidency.
So now someone wants to schedule an appointment several months away, at e.g. 4PM in that new timezone. Has the software been updated to know that that 4PM will be in that newly-announced but not yet valid timezone? Otherwise it will store the time with the current UTC offset, which will be the wrong offset the time that appointment arrives.
So now someone wants to schedule an appointment several months away, at e.g. 4PM in that new timezone. Has the software been updated to know that that 4PM will be in that newly-announced but not yet valid timezone? Otherwise it will store the time with the current UTC offset, which will be the wrong offset the time that appointment arrives.
That’s the half part of the ass I was talking about. Take my “appointment” example and make it a meet up with an old friend. You may not have any location data to work with. If I live in the pacific TZ and I’m meeting up with an old friend in eastern, December 20th at 11am, “store UTC then adjust in the client” would make me 3 hours late.
Note moment's authors now recommend not using moment and using the updated stdlib.
I highly recommend using Luxon for dates in JS. At the very least reading up on the library.
This stuff isn’t simple y’all. “Just use UTC” is a good half assed approach but it can be lossy for many common operations without even considering use cases (an example is storing appointment times where the appointment is in another TZ and you expect the user to physically attend). It can be absolutely bonkers if you have specific user stories that require both standardized (UTC) time and locale adjustments but your user story doesn’t capture that (an example is any kind of regulation that goes into effect where two regulators have existing time rules that can become inconsistent, including but not limited to TZ changes or observation of leap seconds).
There’s been a bunch of words and brainpower spent saying all of this is too complex and we should just discard locale specific time rules entirely. But unfortunately there’s a huge psychological toll that representation of time can take (people literally get injured and die as well), not to mention legal implications that predate any global kind of time system unification efforts.
Time is (currently fundamentally) a necessary complexity that anyone making software can’t just dismiss without harmful consequences and careful consideration.