> 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,

> 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.