4 ms·

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 mee

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.
  - Joeri 10y ago
    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.
    - TorKlingberg 10y ago
      If the user entered a local time it was always ambiguous. Converting it to UTC only hides the ambiguity.

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.
- Joeri 10y ago
  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.
  - TorKlingberg 10y ago
    If the user entered a local time it was always ambiguous. Converting it to UTC only hides the ambiguity.