5 ms·

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

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.