4 ms·

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

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.

sp332 10y ago
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.
- codebeaker 10y ago
  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.
- teraflop 10y ago
  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.
  - fenwick67 10y ago
    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.
    - crazygringo 10y ago
      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.
  - dragonwriter 10y ago
    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.
  - dllthomas 10y ago
    Unless you are meeting up to watch the eclipse...
    - teraflop 10y ago
      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.
valarauca1 10y ago
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.
- joncrocks 10y ago
  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 http://www.bbc.co.uk/news/world-europe-34631326
  - valarauca1 10y ago
    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.
    - detaro 10y ago
      Many libraries use the OS-wide timezone databases (which generally are based on https://www.iana.org/time-zones 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.

sp332 10y ago

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.

codebeaker 10y ago
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.
teraflop 10y ago
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.
- fenwick67 10y ago
  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.
  - crazygringo 10y ago
    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.
- dragonwriter 10y ago
  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.
- dllthomas 10y ago
  Unless you are meeting up to watch the eclipse...
  - teraflop 10y ago
    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.

valarauca1 10y ago

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.

joncrocks 10y ago
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 http://www.bbc.co.uk/news/world-europe-34631326
- valarauca1 10y ago
  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.
  - detaro 10y ago
    Many libraries use the OS-wide timezone databases (which generally are based on https://www.iana.org/time-zones 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.