Hacker News Reader

Comment by sparsely | Hacker News Reader

> A time zone is an approximate (and weird) spacial coordinate system which causes nonlinearities in the representation of time, and unless you want both of those properties it comes with baggage.

That approximate and weird system is how humans tend to think about future events though. You're right that often it is not necessary, but for many usecases (e.g. when a TV show will be first broadcast in the future) they are the most robust model we have.

View on HN

Storing a set of coordinates for the timezone though would be more useful and future proof. The general case is a range which is the timezone bound, but full accuracy means you can store much more specific data.

Exactly. There is one case where time zones are both absolutely necessary and work as expected with no exceptions, and that case is displaying local time.

My assertion is that a very strong argument should be won before they are used for any other purpose.

I arrived 1 hour late for a zoom meeting a few weeks ago. At meeting at which I was presenting. I checked and double checked the calendar event to make sure I arrived at the right time. Daylight savings time hadn't changed for me recently, and nor had it changed for the organizers (who advertised the event in GMT).

The problem was that the calendar advertising the recurring event was set to PST. And daylight savings had changed in California (PST -> PDT or the other way around). The result was that the calendar event shifted by 1 hour local time for me and every other attendee who subscribed to the calendar event.

This situation sucks, and its really confusing to everyone. But I can't think of a way around this whole issue:

- If recurring calendar events weren't set to a timezone (and thus, just worked off GMT), then all recurring calendar events would drift forwards or backwards when daylight savings changes happen

- If recurring calendar events are set to some local time zone, then things like this happen - which really confuses everyone involved.

I mean, sure - in an ideal world we'd get rid of time zones. But until then, it seems like we're stuck with this problem.

(Though at least daylight savings time is slowly being phased out in some countries.)

A great illustration of why we should shun them whenever we can.

Calendar apps are exactly where the full and monstrous complexity of time zones emerges, and I don't envy anyone who works on one.

My case is that the problem doesn't have to happen in the other direction and this unforced error is made frequently. There are a huge class of recurring events where drifting by an hour on the local clock won't make a difference, but either skipping something or doing it twice is bad.

What you're describing strikes me as a bug in the absolute sense: nothing should be displaying PST during a time frame when that time zone isn't in use.

Again, don't sign up to have these problems if you can possibly avoid it.

The solution is to make the calendar aware of all the time zones relevant to an event (e.g. the organizer’s time and the presenter’s time), so it is able to display all the times and warn when timezone changes might be relevant. (Each attendee may have a different time too, but those times do not need to be recorded in the event but can be handled locally on each attendee’s devices.)

There is the extra problem that the standard explanatory names for timezones that appear in the CLDR are very confusing, eg British time is referred to as GMT even though that is wrong for more than half the year in the summer.

Sure, time zones are real† and therefore developers need to model them correctly.

†arbitrary, yes, but real

I'm saying something stronger than it often isn't necessary, I'm saying that storing time zones as part of a time is almost always the wrong thing to do.

For example: if your show is broadcast first in Eastern then in Central time, that's one thing. What if it shows in Canada the next day? All of a sudden you really wish you had modeled space separately from time.

Even when some event is time-zone-gated, this will correspond to one exact moment in time, and for e.g. server provisioning that instant is what matters. Including a time zone can only lead to missing that instant, it can never help you find it.

If I understand your example correctly, it is about using time zones as a proxy for "regions where a TV show might be broadcast", which is clearly inadequate but because time zones are coarse and unrelated to the actual data of interest, not because broadcasting times are represented with timezones. (There might or might not be a second layer of error: 13:00 central time is the same time as 14:00 eastern time, 1 time zone to the east, and pretending they are different is a horrible abuse)

One thing I try to hammer home is that the time zone portion of a time is absolutely NOT to be used for any other purpose than to determine the time value itself. The moment you need that kind of data for other purposes, you should be recording a separate field in addition to the time field.

I even added a write-up about time to the spec: https://github.com/kstenerud/concise-encoding/blob/master/ce...

I appreciate your detailed write-up, which I found reasonable (at least for date & time things, I haven't read others), but most users would be clueless about this separation and will write something seemingly works, only to find it broken later. I also have a concern about the implementation complexity [1], which combined with clueless users can have a bigger effect.

[1] Back when I designed my own serialization format I criticized TOML's decision to add date and time types for the same reason: https://github.com/lifthrasiir/cson#no-additional-types

Yes, the time data is complicated, but then again time is by nature hellishly complicated and difficult to get right. If I reduce scope, it just maintains the status quo we have now, which is everyone doing everything in TZ offsets (that's ISO 8601's fault), and doing it very, very wrong the moment they step out of the tiny confines of event timestamps.

I know this sounds like an "if everyone would just ..." kind of excuse, but poor time implementations really are a big problem in the industry, and I'm hoping to at least provide the tools for knowledgeable people to do it right.

Reply on news.ycombinator.com