How to deal with timezones/DST on portable devices?

[cubeflake]

We are developing a portable device that stores files on an SD card (FAT32 for now, but maybe exFAT in the future). When the device is manufactured, we program it with the current time which is then stored in an RTC.

We only recently realized that this might cause issues when it comes to timestamps. FAT32 has no notion of timezone, exFAT does, but even then we have no way of knowing in which timezone a device is.

That means that the stored timestamps of the files will only be correct if our customer happens to live in the same timezone as us.

We could maybe ask our customer to set the correct timezone via the USB interface or something like that, but that could be annoying for our customers

Does anyone know how other devices such as field recorders, camera's etc deal with this issue?

[eutectique]

We are developing a portable device that stores files on an SD card (FAT32 for now, but maybe exFAT in the future). When the device is manufactured, we program it with the current time which is then stored in an RTC.

If the time is not visible to the client, then set it to UTC.

but even then we have no way of knowing in which timezone a device is.

Why is it important in the first place?

Does anyone know how other devices such as field recorders, camera's etc deal with this issue?

All the cameras that I've had never had this issue. Just set the date/time in the UI and live with it. No time zones, no DST.

[asmi]

Non-connected devices typically let user set date and time, and use it for timestamping.

[nctnico]

There are libraries for this purpose but these are not small as these need to implement daylight savings as well. But it is doable.

Without such libraries there are two options: timestamp in UTC or let the user set whatever time they like (with the requirement to adjust when the daylight savings change). The advantage of using UTC is that you'll have a monotonic timestamp you can always relate back to local time which can help to interpret log files (especially when dealing with a sequence of events spanning hours or even days). The advantage of having a local time is that the users can relate events to their own time.

[NorthGuy]

What is important is the time zone which you have used to set RTC, not where the customer is located.

RTC will wander away from real time eventually anyway.

[Nominal Animal]

Use UTC.

Original IBM PC BIOS and FAT (MS-DOS and Windows) using local time for RTC and timestamps is an anomaly in the computing world, and has only lead to countless problems in a futile attempt to avoid solving a simple one (the UTC to local time conversion) by pushing it on the human users instead.

Using UTC everywhere replaces all those problems with just two: 1) how to sync the clock, and 2) how to display time to the users.

If you have network connectivity, even occasional network connectivity, you can use NTP or SNTP for clock synchronization.  There are even free server pools you can use, if you make sure the device does not query them too often.  Once a day at most, if you have a battery-backed RTC.  The protocols are very simple to use if you do not need millisecond/sub-millisecond accuracy.

Displaying time to users can be solved either by documentation – telling users the filesystem timestamps are in UTC –, or in applications and web pages, using the functionality provided by all OSes and browsers.  In your case, I do believe using the former only, with no NTP syncing, is perfectly acceptable.

(Anything net-connected using local time timestamps is definitely doing things wrong.)

[cubeflake]

Thanks for all the replies guys.

The reason that correct time stamping is kind of important is for when customers pull of their data files of the device, it would be better if all the dates they see on their computer are correct.

However, as NorthGuy said, the RTC clock is going to drift anyway, so we need a way to set the clock anyway and that will fix both issues as the clock will then be set to the customer's local time.

[peter-h]

Yes; any RTC you can afford (say, a 20ppm xtal, perhaps with a single point factory cal) is fairly rapidly going to become just sufficiently irritatingly useless. So you need time sync.

This in turn is a very old problem in embedded systems. You probably know the options, which are

- if there is a PC connection, then with a suitable driver on the PC (another devt/support nightmare) you can sync from the PC (my box implements an HTTP server to which you go with a PC browser, and there is a "set time from PC" option, obviously implemented with a bit of javascript which picks up the PC time and uploads it)
- GPS receiver (U-BLOX etc, down to under €10; need to pick up just one satellite)
- timecode signal (fairly cheap to do but again need to pick up the signal, need to make it multi-country, and a lot of consumer products struggle with poor signal if in a fixed location)
- internet (NTP)
- GSM tower signal (I believe you don't need a valid SIM, or any SIM, to pick up the time, but almost nobody will talk about how e.g. https://electronics.stackexchange.com/questions/404716/leeching-clock-information-from-cell-towers)

I've got a GPS to NTP server product. The GPS also gives you location (need a better signal) and then you can do auto timezone selection.

I would use UTC only if at all possible. Or just give the customer a "set date/time" function, like e.g. cameras have. But they have problems e.g. if you travel with a phone and a DSLR, the phone will timestamp photos in local time (it uses GSM towers, even though it has GPS!) while the DSLR will timestamp in whatever time you loaded into it. I never found a phone camera app (android) which has a "UTC" option. It gets even more funny if shooting from an aircraft which crosses borders