Hacker News Reader

Comment by takinola | Hacker News Reader

No other programming concept has caused me more grief than dealing with time and timezones. It starts to get really mind-bendingly complex once you start thinking about it deeply. That is even before you start encountering the quirks (some places have timezone changes that depend not only on the time of year but also on the actual year). Lesson learnt - choose a library (moment is great) and never think about time again.

View on HN

Except you do still have to think about time, no matter what… Libraries will help with the really messy details, but even the high level requirements have a lot of pitfalls.

“Simple” example that anyone who’s ever worked on a scheduling application will probably be familiar with:

“Get a list with all of today’s events.”

Well, whose “today” (timezone) are we talking about? Server, client, setting in the user account? Or none of the above, and actually timezone at the physical location of the event, if there is one?

And what does “today” mean, anyway? Truncate the date? 00:00-23:59? Business hours?

And what does “today’s event” even mean? Events can cross midnight… Does an event need to start today? End today? Both? Can events span multiple days?

The fun never ends!

I understand the complexity of time, but this scenario doesn't seem all that difficult. Any user expects (I won't get into what they want) to be shown _their_ day, and they expect it to be local calendar time. You _might_ want to show wee hours events, from midnight to just short of 5am. Apps like Teams do a good job of spacially illustrating time as it matters to you _and_ as it matters to others.

I agree with everything other than "moment is great". Even the devs say don't use it any more, and accidentally mutated datetimes have been the source of bugs in apps I've worked on multiple times. Luxon is great though.

Libraries can't paper over the hard parts of dealing with timezones. There are many "right answers" for most date problems. And, they're all what you want for some context. So, the library can't be opinionated about most things.

You just need to understand how time works if you write code handling time.

The really important thing to remember about timezones is they're not a mathematical construct, or a physics construct, or an astronomy construct... They're a political construct. Framed in that light, they have every bit the complexity of having some piece of your code depend on the law (except it's the law of every nation you expect to be running your code in).

To that point: https://devblogs.microsoft.com/oldnewthing/20030822-00/?p=42...

Unfortunately, not many people in our industry really understand the common pitfalls of timezone management, including the people who set the requirements. The classic "I want this to run at 2am each weekday for the user", and then proceed to simply store that as a UTC offset and call it a day (pun intended).

Especially because 99,9999% of the time I don't even care about any of the special cases, and I just want to show a simple date to a user.

And still, you regularly run into issues, because our API or a third party did something silly

It’s because it is not systematic historically. It’s a system full of edge cases

It's also a beautiful maze of nerd snipes. There's apparently some shifting going on inside the earth, combining with the slight variability of the moon's distance, which means various days over a month can be more than a millisecond shorter than average. Good luck integrating that into your date.addDays()

The more precisely you try to measure anything the more confounding factors you encounter. Take length as an example: every material has some coefficient of thermal expansion, and that coefficient can itself change with temperature. Even Zerodur. Every material has a finite speed of sound. If you measure length precisely enough and fast enough, you'll find every material changes length as ambient sounds pass through. So everything is a thermometer, and a microphone, and more since there are many other "parasitic" variables.

moment.js has been deprecated for, what, close to 5 years now? I wouldn't recommend choosing it over any of the modern alternatives.

Reply on news.ycombinator.com