How do devices such as computers or mobile phones obtain the time zone information to automatically set their clock?
I am developing a microcontroller-based embedded system with Ethernet capability and would like to use timestamps in my log files. I can get the UTC time from SNTP but am not sure where or how to get the time zone info.
There are several approaches, which I'll list in order of approximate accuracy:
The device's time zone is set either by TZ environment variable, or some other mechanism depending on OS. This is the most common approach, and is the most accurate - presuming that the person in physical possession of the device knows which time zone it is going to be used in. It does, however, require the person to enter a time zone in some configuration setting, or choose it from a list, etc. Typically the choice is persisted, so it can be restored on startup.
(Global Positioning System / Global Navigation Satellite System)
A device that has geolocation capabilities, such as a car or mobile phone, can leverage the devices current position to determine an appropriate time zone from latitude and longitude coordinates. This is often an opt-in approach, as sometimes even if the device is capable of determining it's location, it's still a choice by the user to leverage the information for this purpose. For example, Android 12 and higher has an opt-in location-based time zone detection feature.
In addition to the location, the device also needs a time zone map, or an index calculated from a map, or a library that uses a map or an index. Maps can be opinionated though, as borders around the world are often poorly defined and sometimes in dispute. Nonetheless, one of the most reliable and commonly used maps for this purpose comes from the Timezone Boundary Builder project, which layers time zone boundaries on top of OpenStreetMap data. (Indeed, it is used by the Android feature previously mentioned.) You can find a list of software libraries and services that leverage this data here. If your device has GPS or other geolocation capabilities, then you can pick a library from that list and use it in your code to determine the time zone automatically.
(Network Identity and Time Zone)
NITZ can be used on devices that have GSM chips for mobile communications. Basically, the devices picks up the current time and time zone from the cell tower that it is communicating with. The time itself is accurate only on the scale of minutes, so often it is disregarded in favor of an NTP-based time source when one is available.
According to the NITZ specification, the time zone information consists only of an offset from UTC, and a flag indicating the DST adjustment, if there is one. While this is fine for setting the current local time, it may not uniquely identify a time zone globally. Thus, it may or may not suit your needs - depending on the nature of your device and software. For more on this point, read the timezone tag wiki, especially the section titled "Time Zone != Offset".
Also, a common problem with NITZ occurs when more than one cell tower can communicate with a device near the border of two time zones, or when one tower needs to serve two different time zones. In such situations the device can receive mixed signals, and may respond by picking the wrong time zone, or may respond by alternating back and forth between two time zones. This situation often leads people near such borders to disable automatic time zone selection and revert to manual selection if they're able to (such as on a mobile phone).
Yet another problem with NITZ is that the time zone information is only as reliable as the setting that the mobile carrier gave to the cell tower. Sometimes a specific cell tower can have the wrong time zone setting, or may not have up-to-date time zone information (such as the date and time of a DST transition). However, this is mostly a problem with older cell networks. Most modern carriers automate this.
There are many mechanisms for guessing a users approximate location based on their IP address. Often the guess is close enough to pick a time zone, using the same approach as if you received the location via GPS. However, the location can also be in error - especially if the device is connected to a private network or VPN. Thus, using this approach for setting the time zone in such situations can have mixed results - sometimes setting the local time wildly incorrect. Use with caution, especially on devices that may be in motion.
One way to mitigate the challenges with the above approaches is to combine them:
Use automatic information in order of accuracy depending on device capabilities. GPS, then NITZ, then IP geolocation.
Allow the user to turn off automatic selection and choose a time zone manually when needed.
The best example I can give of this is the "Set Time Zone Automatically" feature of Windows 10 and newer. When disabled, the user picks a time zone manually. When enabled, a time zone is picked based on the most accurate location information available to the computer, and leverages an index of time zone location data provided by Microsoft with the operating system - which is updated periodically via Windows Updates as necessary.