Hacker News Reader

Comment by eyelidlessness | Hacker News Reader

This could be addressed at least for the most common cases by making the API more explicit: if you want a non-zoned DateTime, you have to say so and accept its caveats. Otherwise you’re getting a (local by default) zoned DateTime and its TZ can be manipulated to accomplish other date/time math in a predictable way.

The mix of zoned/not is a valid use case but almost certainly a specialized one that shouldn’t be the core API.

View on HN

> The mix of zoned/not is a valid use case but almost certainly a specialized one that shouldn’t be the core API.

I'm curious, where is this ever a valid use case? The idea of an unzoned DateTime doesn't make sense to me. I guess if you're building software that lives in orbit or on other planets?

My personal use case that I explain in the “just use UTC isn’t good enough” case: I take meds 2-3 times a day that are short acting and time sensitive. I need them at ~9am and ~1pm to function. Local time, wherever I am.

For the unzoned case I need my reminders to notify me at the same local time wherever I travel. For the mixed case I need to be able to apply local changes where the unzoned solution isn’t available.

These are ADHD meds, I have severe executive dysfunction and I depend on reminders for this. Traveling from Seattle to DC, this is literally the difference of whether I can function at all before lunchtime. Traveling further I might as well not go at all.

I want to wake up at 8:00 regardless of my timezone. I don’t want to wake up at “8:00 NYC” when I’m in Europe nor should I need to adjust the alarm every time I change timezone.

That’s a good case for an unzoned time data type - storing a time without an associated date or timezone. There are some scheduling use cases where such a type is useful - such as your alarm clock example, or suppose a chain of retail stores has standard opening hours of 9am-5pm regardless of the time zone the store is in.

But a combined datetime (both date and time) in an unspecified non-UTC timezone is far less useful. As I mentioned in another comment, there are some rare use cases where it is genuinely appropriate, but far more often if you give people such a type they’ll use it to store data in a single specific time zone, without being explicit about what that time zone is-which is a bad practice.

From a data modelling perspective, it's nice to have them. When your input/output data has unzoned datetimes, you need to model them somehow, and it's better to have a competent implementation than something hand-rolled. I agree that you should avoid them in greenfield designs, but I don't think that's sufficient reason to exclude them from libraries.

Here is a rare, if potentially real use case: a university has campuses in multiple countries, maybe they have one in Europe, one in the Middle East and one in Asia. Some of their units are taught across all three campuses and have common exams. They try to hold the exam at as close as practicable to the same time, but they aren’t going to make students take it in the middle of the night - especially when students at another campus get to sit it during the daytime, that would be unfair. So they’ve scheduled it for 9am local time on 30 May 2022 - across all their operating time zones.

That said, these kind of scenarios are rare. A non-UTC datetime in an unspecified timezone is much more likely to be in some particular yet unspecified timezone, or even to be an incoherent mix of data from different time zones, than to be the one of these rare cases where having a constant local date and time across multiple time zones is actually useful.

Arguably, library designers should not attempt to cater for these rare use cases. Doing so is adding complexity which is far more often going to be a cause of harm (people using an unzoned datetime type when they shouldn’t) than a benefit

One use case is storing future events, as floating DateTime + location. This makes it possible to handle timezone rule changes, unlike storing a zoned DateTime on its own.

Another is when you treat the timezone and datetime separately. Imagine an internal app for conference room bookings with a form that lets you input a DateTime + office building (which some Ruby or whatever backend then uses to compute the localized time). The JS DateTime input library would deal with a non-localized DateTime only.

Reply on news.ycombinator.com