Handling Time Zone in JavaScript (2019) | Hacker News Reader

Handling Time Zone in JavaScript (2019)

medium.com

25 pointsfagnerbrack6 comments

At my last job we had... very difficult situations caused by TZ misunderstandings and mishandling (wish I could say more but we resolved them!). One of the hardest things for many on my team to grasp was that TZs of the same offset weren’t interchangeable. I spent just a little time to shed my built in “do it right” mnemonics and just took a dive into the time regulation history of one of our customers’ geographic centers and contrasted it with the regulation history of one that happened to line up. I also pointed out legislation in my own locale (WA state) which has passed recently and, pending federal approval, will eliminate standard time (an idea I’ve wanted to pursue for years and I’m delighted made its way through our legislature). That exploded some brains.

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.

> “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.

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.

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.

Reply on news.ycombinator.com