Interpretation of file modification timestamps

General discussions and questions abound development of code with MicroPython that is not hardware specific.
Target audience: MicroPython Users.
Post Reply
User avatar
aivarannamaa
Posts: 171
Joined: Fri Sep 22, 2017 3:19 pm
Location: Estonia
Contact:

Interpretation of file modification timestamps

Post by aivarannamaa » Fri Sep 18, 2020 8:58 am

I know that os.stat(filename)[8] is an integer denoting seconds from the epoch (and that the epoch is 2000-01-01 in most devices and 1970-01-01 in the Unix port).

My question is about timezones.

When I'm doing os.stat(filename)[8] in CPython, I know I get a UTC-based timestamp. What can I assume in MicroPython? RShell uses some heuristics to decide whether to treat the value as UTC or local time. Is this the best I can do?

My specific problem is how to implement device time synchronization in Thonny IDE. When I set the RTC to UTC time, then Thonny's file browser only needs to take device's epoch into account when interpreting file timestamps. The downside is that when the user does `time.locatime()` the result may be unexpected.

Are there some official recommendations regarding this? Documentation of RTC.init doesn't mention this issue. https://docs.micropython.org/en/latest/ ... utime.html says: "However, embedded ports use epoch of 2000-01-01 00:00:00 UTC".

If you were using Thonny (and your local time differed from UTC) would you prefer Thonny to set your device's RTC to UTC or your local time? In both cases Thonny can display file timestamps in local time but in the latter case it must make adjustment to the default interpretation.

(There will be option to turn off time synchronization altogether eg. if you are using NTP).
Aivar Annamaa
https://thonny.org

User avatar
dhylands
Posts: 3821
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: Interpretation of file modification timestamps

Post by dhylands » Fri Sep 18, 2020 11:04 pm

Most ports of micropython have no notion of timezone. The Loboris ESP32 port of MicroPython added support for a configurable timezone (at compile time)

For most ports os.stat will return whatever time your RTC was initialized to. For the Loboris port, if you use NTP to intiialize the RTC then I think that the RTC will contain UTC time.

On the unix port time.localtime and time.gmtime return what you would expect (and there is no RTC).

The VFAT filesystem normally stores local times on the filesystem. Most linux/unix filesystems store UTC times on the filesystem.

I think that almost all of the ports use the RTC timestamp for the filesystem. I don't recall whether the loboris port does adjustments to store local time when using an external SD card or not.

When there is no notion of timezone, then using localtime for the RTC is the natural thing to do.

The unix port and the loboris port both have a notion of timezones. Both of these platforms use an epoch of 1970. The other ports all use an epoch of 2000. I'm not sure what the PyBoard D series does (I'm pretty sure it uses an epoch of 2000 but I don't know about timezones).

Note that most RTC clocks don't use an epoch and know the year/month/day/hour/minute/second directly.

I think that for many people using UTC for the RTC would be unexpected, especially since there is time.localtime would now be incorrect.

If there was the ability to specify an offset between localtime and gmtime then using UTC for the RTC would make perfect sense.

Also, since SD cards are typically VFAT, their timestamps will typically be in localtime (just something else to keep in mind).

User avatar
aivarannamaa
Posts: 171
Joined: Fri Sep 22, 2017 3:19 pm
Location: Estonia
Contact:

Re: Interpretation of file modification timestamps

Post by aivarannamaa » Sat Sep 19, 2020 5:09 am

Thank you for this comprehensive answer, again!

I guess I'll make an option with choices ["automatic", "local time", "UTC"].

Another port which deals with timezone is Pycom. They allow specifying a single integer timezone which is used by utime.localtime (local_time = utc + timezone). IMO this would be good fit for the other bare metal ports as well, no need for a timezone database. A tool like rshell or Thonny can set this timezone automatically together with RTC synchronization, so the user doesn't need to be even aware of it.
Aivar Annamaa
https://thonny.org

Post Reply