I am programming for an embedded device and I want it to display the local time. I know I can get the UTC time by NTP or SNTP. However how can I convert it to the local time if I do not want the user to input the timezone manually? Obviously I need a method that I can get my timezone from the network. Is there any network protocol that can do this? If this method exist, is it reliable?

I am programming for an embedded device in which there is no OS. Therefore I need the "low level" method, for example a protocol rather than a Windows function.

Thank you very much.

  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide your own answer and accept it. – Ron Maupin Aug 7 '17 at 0:34

There is no protocol as such but you could do a GeoIP lookup to get your approximate location and map the location to a timezone.

MaxMind offers a GeoIP database that is accessible via various methods, see http://dev.maxmind.com. You can even get the data in a CSV file and store locally but given that you are on an embedded device I suspect you are low on storage and might prefer to just do an online lookup. They have a convenient API that can do a lookup on the requestors IP address, so you don't need to use any other method to find your external address. In addition the returned data includes timezone information so it appears you can get all you need with a single HTTP call. See https://www.maxmind.com/en/locate-my-ip-address

I put together a few lines of Python to show how this could work:

#!/usr/bin/env python

import urllib, json
url = "https://js.maxmind.com/geoip/v2.1/city/me?referrer=https%3A%2F%2Fwww.maxmind.com"
response = urllib.urlopen(url)
data = json.loads(response.read())
print data['location']['time_zone']
# to pretty print all returned data
#print json.dumps(data, sort_keys=True, indent=4, separators=(',', ': '))

And when run:

kll $ python ip2tz.py
Europe/Stockholm

It would probably be wise to cache the result so that you can get your timezone even if your Internet connection is down.

The answer @kll gave is probably the best you can do, although geo-location is getting worse all the time with the IPv4 address shortage because some users are using addresses assigned to RIRs in other continents. I know of at least one company that will only use ARIN (North America) addresses for its addressing, regardless of the site location anywhere in the world, because of the problems with sites being blocked, based on geo-location, from certain regions.

The most reliable method would be to use GPS, but that can be problematic indoors, and it would require extra hardware in your device. On the positive side, it would give you the most accurate time, too.

  • Which RIR handed out an address has little bearing on the accurateness of GeoIP information as the location is primarily collected from other information sources anyway. – kll Oct 27 '15 at 14:20
  • 2
    Well, that depends on the geo-location service used. For instance, most geo-location services think I'm in Virginia, but I'm actually in Texas. My ISP is headquartered in Virginia. Geo-location is a tool with some problems, but its the best that we have for getting location strictly using the Internet. – Ron Maupin Oct 27 '15 at 14:25
  • Absolutely, I didn't mean to imply it's perfect.. it's quite far from it ;) I merely meant to highlight that information is usually collected from other sources and that those have higher priority when determining where an IP is located. This naturally also depends on who is building the geo-IP database. – kll Oct 27 '15 at 14:46

You can

  1. Get universal time over NTP
  2. Look up the devices IP address (if implementing on the client remember to get the public IP from a server on the Internet rather than using a local private IP) in a geolocation database to get a TZ ID.
  3. Look up the TZ ID in the TZ database to get the rules for that timezone.
  4. Convert those times to local time.

However there are some problems with this approach.

The first is that network boundries don't always line up with political or timezone boundries. This is especailly a concern in countries like the US and Canada that have multiple timezones.

The second is that implementing this process locally on an OS-less embedded device which presumablly has limited memory will be difficult. The geoip and TZ databases are not exactly small.

The third is that geoip and TZ databases both need to be updated regularlly and can lag behind reality.

If your embedded devices talk to some kind of server i'd look at implementing things server side where the large and volalite databases are less of a burden.

Personally I would suggest only using geolocation data to set an initial default. This avoids systems unintentially jumping timezones for no obvious reason.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.