Thanks for the heads up. The test code isn't written as carefully as the library code.

Meanwhile mock_ftplib.py has been removed in the repository because I'm using another mocking approach now (see ticket #98 and test/scripted_session.py​). Nevertheless, there could be similar problems in the new code. I guess I'll check the tests when I'm working on #134, which I need to finish before the release of ftputil 4.0.0. I use the word "need" because dealing with #134 means a backward-incompatible change and I don't want to release a version 5.0.0 shortly after 4.0.0. ;-)

Again, thank you. :-)

I was just wondering why you would still use mock_ftplib.py and noticed that in the Mercurial repo browser the master bookmark is at January 2019 whereas the last commits on master are actually from the start of this year.

I pushed deliberately with -B master now and the repo view seems to be updated. I had assumed that the bookmark in the repo on the website would be updated if I had pushed the bookmark in the past.

I worked on ticket #134 during the last days and in the course of that hopefully made the tests more robust regarding year changes.

There's still one thing that depends on my environment, and at the moment I don't know how to fix this. In the integration tests test_real_ftp.py is a test method test_time_shift that indirectly uses the function

def expected_time_shift():
    """
    Return the expected time shift in seconds.

    Unfortunately, the calculation may depend on the timezone of the server,
    i. e. the timezone used in directory listings coming from the server.

    So, depending on your test environment, you may need to change this
    function for your environment. _If_ you need an adapted
    `expected_time_shift`, please contact me (my e-mail address is in the
    ftputil documentation).

    In my particular case, I use Pure-FTPd as FTP server for the integration
    tests. At some point, it returned listings in the local timezone of the
    server, later it used UTC time, and now it uses the local timezone again.
    I wasn't able to find out why or how I can control this.
    """
    raw_time_shift = (datetime.datetime.now() - datetime.datetime.utcnow()).seconds
    # To be safe, round the above value to units of 900 s (1/4 hours).
    return round(raw_time_shift / 900.0) * 900

This function has hardcoded knowledge about the settings of my local FTP server I use for testing. As far as I can tell, making this environment-independent would require an implementation similar to synchronize_times which wouldn't use ftputil to get the timestamp of the temporary file, but instead a command line client and parse the output of the client to determine the date. However, this would contain similar code to synchronize_times and hence wouldn't be that useful because this code may contain the same or similar bugs as synchronize_times (if there are any).

I guess long-term the best solution for the integration tests would be to create a container image that contains the FTP server with its environment (namely the timezone) and the test data.

Another approach could be to use a different FTP server whose configuration allows setting the time reported by the server to UTC. I didn't find such an option for Pure-FTPd.