Custom Query (120 matches)


Show under each result:

Results (4 - 6 of 120)

1 2 3 4 5 6 7 8 9 10 11 12
Ticket Resolution Summary Owner Reporter
#134 fixed Assume UTC for directory listings from server schwa schwa

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 or in the .
  • 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). If 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.

#132 fixed Simplify `ftputil.error` schwa schwa

The FTPError class and some other code in the ftputil.error module use a keyword argument original_exception. Since ftputil now targets only Python 3.6+ and Python 3 has exception chaining, we don't need a custom mechanism to refer to previous exceptions.

#131 fixed Unix time parser uses wrong year if server time is in the next year relative to client time schwa schwa

The method ftputil.stat.Parser.parse_unix_time is responsible for parsing unix timestamps in directory lines. The code contains the following heuristics to guess the correct year on the server side:

# Try the current year
year = time.localtime()[0]
st_mtime = self._mktime((year, month, day, hour, minute, 0, 0, 0, -1))

The problem with this code is that it implicitly assumes that the year on the client side is the same as the year on the server side. This assumption is wrong if the years actually differ. For example, if the directory line on the server is

-rw-r--r--   1   45854   200   4604   Jan 01 01:49   index.html

but the local time on the client side is 2019-12-31T23:49, the code assumes that the January in the directory line refers to the previous January 1st from the point of view of the client. Consequently, the st_mtime of the stat result is about one year in the past for a file that was just created.

1 2 3 4 5 6 7 8 9 10 11 12
Note: See TracQuery for help on using queries.