I am writing some data collection software (in python) that will transmit data to the cloud. I am including a timestamp (using the standard datetime module included with python) in the data record so that the time is documented in the cloud datastore. It will run on an embedded linux device.

I am between a few architectural ideas for how to handle the timezone of the devices and the accuracy of the timestamps.

My thoughts are that I will use an NTP server to obtain the UTC time for the linux distribution which will provide an accurate time for all the applications running on the device. However I am unsure what I should set the timezone to on the device itself.

My concern is that if I set the timezone to the local time and it happens to be wrong, then not only will the local time be wrong, but when my application gets the UTC time from system time it will also be incorrect, even though it was negotiated previously by the NTP server. The timezone may be set incorrectly by whomever installs the deivce. I could mitigate this by including a GPS module in the device which can negotiate the GPS time to configure the system time, but this seems like extra hardware that would be unnecessary.

The other idea would be to have all devices timezone set to UTC and not change based on the location of the device. Then I can be sure that the UTC timestamps I send to the cloud are accurate, but I lose information about the local time unless I also send location info to the cloud database.

I'm not sure if there is a preferred method for setting system time on IoT devices such as this, but I would like some guidance.

  • "if I set the timezone to the local time and it happens to be wrong, then not only will the local time be wrong, but when my application gets the UTC time from system time it will also be incorrect" why do you think this?
    – Ewan
    Commented Jul 31, 2018 at 15:39
  • The application retrieves the UTC time from the system time. If the timezone of the device was set incorrectly, then the UTC time will be calculated improperly as well. As I understand it anyway.
    – Alex
    Commented Jul 31, 2018 at 15:40
  • You mean the timezone is incorrect and the time is also set incorrectly to compensate, so that an apparently correct local time is shown?
    – Ewan
    Commented Jul 31, 2018 at 15:56
  • @AlexEshoo: If the local timezone is set to US East-coast, but I am actually in Europe, then the conversion from UTC to local time will show the wrong time for where I am, but the reverse conversion (local time to UTC) will have the same error in the opposite direction. As a result, the round-trip conversion UTC -> local -> UTC will show the correct UTC time. Commented Aug 1, 2018 at 11:10

2 Answers 2


You outline two distinct problems

  1. Find out (on the device) the correct time

    If you are logging data with a timestamp you will want to use the correct UTC datetime. As you note this can be discovered via a NTP server.

  2. Find the local timezone for the device

    Its less clear why you need this information. But it's next to impossible to retrieve as it is in some ways a user preference.

    In theory with a non-movable device, if you can locate the device with enough accuracy you can look up the timezone that applies to that location at that time.

    Since the only real need for local time is to present it to a user, I would simply ask them to choose a timezone.

  • Thanks for the suggestions. The devices are stationary, the primary interest for the local time is that service technicians generally use the local time in their reports, which can cause some confusion, so I was considering offering both. My concern though, is that if I get the utc datetime from the python datetime module while the system time is set to the incorrect timezone, it my retrieve an invalid time. I'm not sure if that is the case. Do most linux distributions store the UTC time as system time but display a local time based on timezone setting?
    – Alex
    Commented Jul 31, 2018 at 17:29
  • 2
    the only way you can get the incorrect UTC time is if the time is incorrectly set. If you get the correct time via NTP you can set the correct time. the timezone is irellevant
    – Ewan
    Commented Jul 31, 2018 at 18:22
  • "Since the only real need for local time is to present it to a user..." An event happened at 14:30 UTC. Did that event take place during business hours?
    – Blrfl
    Commented Jul 31, 2018 at 19:03
  • @Blrfl yup, somewhere in the world that was in business hours
    – Ewan
    Commented Jul 31, 2018 at 19:52
  • I disagree regarding that local time is only for communication to the user. From the local time you can tell at what point in the usual day the device is used. E.g. some users do action X just after getting up while others do after having had lunch.
    – marstato
    Commented Aug 3, 2018 at 5:12


Report your answers in UTC.

In almost ANY situation where you are displaying or reporting on time based data, the timezone of interest will NOT be the timezone where the data was collected, but rather the timezone of the VIEWER of the GUI or REPORT.

This is especially obvious and critical if you are collecting data from devices that maybe in different timezones.

It's hard to guarantee the timezone of the device will be set correctly, because typically its NOT (because nobody cares). Only if it generates human viewable data about dates would it need to know a timezone.

  • This is the right answer IMO. Don’t send a time stamp at all. The service receiving the data records the UTC timestamp upon receipt.
    – RubberDuck
    Commented Aug 1, 2018 at 0:03
  • 2
    For some situations that works. But often not so. Like if you lose connectivity between the IOT device and the cloud with your server (or server down for maintainance). You get better robustness if you timestamp the records and put them into a queue for cloud delivery. Whether or not this is an issue depends on the details of your IOT device and circumstances, but I've seen many cases where this queuing is helpful. Commented Aug 1, 2018 at 0:54
  • Indeed, the timestamp of when the data is collected is more critical to me than when it is delivered to the cloud, especially since I buffer it somewhat on the edge first for cost optimization. The reason I chose the other answer is because my question was not about whether I should use UTC for the timestamp (I have been already) it was how to configure the device's system clock. I felt the other answer touched on that more. I also read more on the Hardware clock manpage which helped explain the linux clocks.
    – Alex
    Commented Aug 1, 2018 at 12:13
  • @AlexEshoo - I believe you misunderstood or missed the point of my answer. If you are using UTC, you don't NEED to configure the devices clock (to know anything about timezones). That has NO VALUE, unless the device is generating a GUI, and displaying data in the local timezone to the user (a rare situation). Commented Aug 1, 2018 at 14:08
  • 1
    @AlexEshoo Yes, the clock APIs work in UTC. ALL you described in your question you can do best without setting the timezone or worrying about it. IF you have a front panel, and need to display the local time clock, for that purpose alone, having the timezone is important. Commented Aug 1, 2018 at 14:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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