Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com