Hacker News Reader

Comment by codebeaker | Hacker News Reader

Makes a classic "falsehoods programmers believe about time" mistake.

The example (which is not so uncommon) that an appointment is set in timezone X, author of the service storing the appointment helpfully converts to UTC, timezone of the originating country changes and then the "return" from UTC to source timezone is incorrect, because now UTC-0600 is actually UTC-0700.

In short, any conversion that reduces precision is flawed. Dropping timezones after normalizing them to a canonical format makes it impossible to restore the conversion.

View on HN

    Dropping timezones after normalizing them to a canonical
    format makes it impossible to restore the conversion.

Except this isn't true.

Normalizing TimeZones converts them to ZULU/GMT. You can de-normalize ZULU/GMT to any timezone easily and well within the UTC standard by converting them back to the local timezone. No data is lost, and the standard makes this process transparent.

Actually converting from Zulu to Local should always be done on the client side as their locality settings _should_ include a timezone.

This presumes, of course, that you can ALWAYS know in advance what UTC will be.

In practice there are edge-cases that you can't account for when the theory meets the practice of the messy, real world.

For example, last year Turkey decided, with a couple of days notice, to delay the daylight savings switch [1]. If you did things in UTC, you would have no idea which of your dates was now wrong, which ones that needed to be fixed.

Storing UTC might be useful in its own right, but if you're looking for correctness, you need to store the details and not discard the extra information.

[1] http://www.bbc.co.uk/news/world-europe-34631326

I have to ask...

What time encoding format _can_ deal with changes like this? Are their libraries that update often enough?

Also provided the Host OS had the proper time offset the UTC conversion would work fine, even for cases of fractional-hour timezones. So this can would be covered if the client updated their TZ locality.

Many libraries use the OS-wide timezone databases (which generally are based on https://www.iana.org/time-zones), so as long as you update your OS regularly (or explicitly when notified of a timezone change) you should always be up-to-date. The proper way to store (edit: future) times attached to a location is thus to keep a local timestamp with a named timezone (e.g. "Europe/London"), not an offset.

Local time plus time zone is not a perfect solution either. Times stored only as local time are not canonical. With DST some hours happen twice. You can never find out in retrospect which moment a local time refers to if it falls inside one of those magic hours.

If the user entered a local time it was always ambiguous. Converting it to UTC only hides the ambiguity.

I'm not sure I buy your example. If you save the time in the local time, then the time zone changes, the stored date will now be wrong. If you convert to UTC, and update your time zone tables when the time zone changes, then when you convert back the time will be correct.

I think the point is that if you store local time, and have a decently maintained time zone handling library, the library will adjust correctly for before/after the switch, but only if you store in the local time.

Of course it can't happen by magic, and you rely on the authors of the timezone libraries (a thankless task in itself), but if you remove a dimension of your data, nobody can ever help you.

I think you're missing the point of the example. When I make plans to meet someone "at 10AM Central time on Friday", I don't mean "let's meet at UTC epoch 1489762800". I mean "let's meet when the clock says 10:00". If the government suddenly decided to cancel daylight saving time on Thursday, then our meeting would still happen at 10:00 on Friday, even though in absolute (UTC) terms it would be an hour earlier.

A calendar appointment isn't identified by a UTC instant; it's identified by a predicate.

Another example is recurring events. Let's say I have a meeting every Friday at 4PM Central in Chicago. That's UTC 11:00 now, but it was UTC 10:00 last week.

Which also makes it really interesting for people in other time zones. E.g. my recurring meetings, defined in eastern time zone, are the same for me this week as last week (thank goodness) -- but they've moved by an hour for people in other countries who are also in the meetings.

Yes, all of the following are possible needs:

(1) event scheduled for 7:00pm local time in a certain place on a certain date, that needs to be at that local time regardless of whether the government changes to time zone of that locality, or changes DST rules.

(2) event at 7:00pm Central Time ona certain date, that needs to occur at that time in the regardless of DST date changes.

(3) event at 7:00pm CST, which has a fixed offset from UTC.

Unless you are meeting up to watch the eclipse...

Ha, fair point!

But it's only a small step farther to allow scheduling an appointment relative to an arbitrary time zone, instead of the one you happen to currently be in. Which naturally includes UTC, for situations where astronomical time is what you really care about.

Reply on news.ycombinator.com