Opened 2 weeks ago

#134 assigned defect

Assume UTC for directory listings from server

Reported by: schwa Owned by: schwa
Priority: major Milestone: 4.0.0
Component: Library Version: 3.4
Keywords: server listing utc timezone time shift Cc:


For a long time, ftputil has assumed that FTP servers present dates and times in directory listings in "their" timezone. I think this is a problem for several reasons:

  • ftputil can't know which timezone the server is in. Even if the user specifies a time shift, it's a constant value and may not apply to dates/times in the past.
  • Having a server use UTC for its timestamps makes sense because using a timezone may lead to skipped or double hours for daylight saving time switches. So I think the assumption is justified anyway that most servers will use UTC.

Therefore, ftputil should assume the server uses UTC in listings. Of course, this assumption may be wrong, but in that case there's still the time shift concept (local server time minus local client time). If the server time in listings is actually UTC, the time shift is zero (see also next paragraph). The server doesn't use UTC, a time shift can still be set with FTPHost.set_time_shift.

On a related note, os.path.getmtime returns the time as seconds since the epoch (i. e. UTC), so comparing (UTC) timestamps from the server and the client become trivial, apart from the precision of the server times.


  • Change code for Parser.parse_unix_time and Parser.parse_ms_time to assume UTC. Adapt tests.
  • Change code in file_transfer.source_is_newer_than_target and adapt tests.
  • Possibly adapt tests for download_if_newer and upload_if_newer.
  • Update documentation. Include a more thorough explanation of the problems with local times and why UTC is the best bet.

This change is backward-incompatible. Because I came to the above conclusion only now, there hasn't been a deprecation warning about this change in past ftputil versions. However, I think it would be overkill to release a version ftputil 3.5 only to add a deprecation warning before the changes. Also, normally the impact of this change should be small since most people will use download_if_newer and upload_if_newer, which hide the exact definitions of the individual timestamps of server and client.

Change History (0)

Note: See TracTickets for help on using tickets.