3 ms·

Because the local time is the thing that you have immediate access to, with no additional conversions applied. Every conversion requires an external source of

Because the local time is the thing that you have immediate access to, with no additional conversions applied. Every conversion requires an external source of information. Converting from local time to time zone requires measuring the system clock drift. Converting from time zone to UTC requires knowing which time zone you are in. Converting from UNIX timestamp to UTC requires measurements of the earth’s rotation to know how many leap seconds to add. I’d propose going in the opposite direction: All timestamps should indicate which clock they were produced from. There is no such thing as a global clock, only conversions between your local clock and the UTC clock.

amluto 3y ago
> Because the local time is the thing that you have immediate access to, with no additional conversions applied. Only in the sense that BIOS systems historically programmed non-DST-aware local time into the RTC. Other than that, you actually have no-conversion-needed access to UTC or something UTC-like. Linux mostly tracks the conversion from the hardware clock (TSC, for example) to UTC. NTP gives UTC, and GPS gives something that is a lot closer to UTC than to local time.
- MereInterest 3y ago
  > Only in the sense that BIOS systems historically programmed non-DST-aware local time into the RTC I would love to hear proposals on how, at a hardware level, you would track Daylight Saving Time. Not just how a Daylight Saving Time correction would be applied, but also how the hardware would receive updates to dates at which DST is observed, within which geographic borders, and how to handle conflicting updates for locations where the geographic borders are contested. > you actually have no-conversion-needed access to UTC or something UTC-like No, you don't. You may have access to an API that has already applied conversions when by the time a result it returned to you, but that is significantly different than having direct access to a universal clock. (And assumes that such a universal clock even exists.) Your clock is a hardware-based oscillator, with a counter for the integer number of oscillations that has occurred. You do not have a UTC clock. You have an experimentally-determined and infrequently-updated conversion between your clock and the UTC clock. > NTP gives UTC No, it doesn't. NTP gives an approximation to UTC, and is only available when you have a network connection available. The accuracy of that approximation depends on quality of that network connection, and whether it has asymmetric delays. > GPS gives something that is a lot closer to UTC than to local time While true, this is only available for devices that have GPS capabilities, in a location without sharp elevation changes that would delay GPS signals. Everything has a conversion factor. Everything. If you record the original measurement and the conversion factor used, you can recover from errors in the conversion. If you only record the measurement after conversion factors have been applied, you cannot.
  - o11c 3y ago
    >I would love to hear proposals on how, at a hardware level, you would track Daylight Saving Time. Traditionally the BIOS ignores it, and Windows on reboot detects if the clock needs to be adjusted according to the latest rules that it knows about. This failed quite often in practice. Linux systems using tzdata are much more reliable (Windows is still very buggy with historical data), but UTC time support on non-Linux systems was flaky for a long time, leading to bad API design in languages historically. `timegm` despite being a critical and irreplaceable function is still not in POSIX, for example (though it is widely supported in practice)

amluto 3y ago

> Because the local time is the thing that you have immediate access to, with no additional conversions applied. Only in the sense that BIOS systems historically programmed non-DST-aware local time into the RTC. Other than that, you actually have no-conversion-needed access to UTC or something UTC-like. Linux mostly tracks the conversion from the hardware clock (TSC, for example) to UTC. NTP gives UTC, and GPS gives something that is a lot closer to UTC than to local time.

MereInterest 3y ago
> Only in the sense that BIOS systems historically programmed non-DST-aware local time into the RTC I would love to hear proposals on how, at a hardware level, you would track Daylight Saving Time. Not just how a Daylight Saving Time correction would be applied, but also how the hardware would receive updates to dates at which DST is observed, within which geographic borders, and how to handle conflicting updates for locations where the geographic borders are contested. > you actually have no-conversion-needed access to UTC or something UTC-like No, you don't. You may have access to an API that has already applied conversions when by the time a result it returned to you, but that is significantly different than having direct access to a universal clock. (And assumes that such a universal clock even exists.) Your clock is a hardware-based oscillator, with a counter for the integer number of oscillations that has occurred. You do not have a UTC clock. You have an experimentally-determined and infrequently-updated conversion between your clock and the UTC clock. > NTP gives UTC No, it doesn't. NTP gives an approximation to UTC, and is only available when you have a network connection available. The accuracy of that approximation depends on quality of that network connection, and whether it has asymmetric delays. > GPS gives something that is a lot closer to UTC than to local time While true, this is only available for devices that have GPS capabilities, in a location without sharp elevation changes that would delay GPS signals. Everything has a conversion factor. Everything. If you record the original measurement and the conversion factor used, you can recover from errors in the conversion. If you only record the measurement after conversion factors have been applied, you cannot.
- o11c 3y ago
  >I would love to hear proposals on how, at a hardware level, you would track Daylight Saving Time. Traditionally the BIOS ignores it, and Windows on reboot detects if the clock needs to be adjusted according to the latest rules that it knows about. This failed quite often in practice. Linux systems using tzdata are much more reliable (Windows is still very buggy with historical data), but UTC time support on non-Linux systems was flaky for a long time, leading to bad API design in languages historically. `timegm` despite being a critical and irreplaceable function is still not in POSIX, for example (though it is widely supported in practice)