Timeline
Apr 13, 2020:
- 6:02 PM Ticket #137 (Update documentation for version 4.0.0) created by
- Some of the following items apply more to the announcement than to the …
- 5:51 PM Ticket #134 (Assume UTC for directory listings from server) closed by
- fixed: This is implemented as of [7e2299845b86].
- 1:49 PM Ticket #136 (Clear cache when setting a new time shift) closed by
- fixed: This issue was solved in [68fd6debe77c].
- 1:47 PM Ticket #136 (Clear cache when setting a new time shift) created by
-
FTPHost.set_time_shift(new_time_shift)must invalidate (i. e. clear) …
Apr 11, 2020:
- 9:59 PM Changeset [1934:df2e1f889303] by
- Remove debugging `print`s
- 9:57 PM Changeset [1933:e84ebbbace3b] by
- Make check/rounding part of `set_time_shift` Before, `__assert_valid_time_shift` and, after the assertion, `__rounded_time_shift`, were called only from `synchronize_times`. However, it makes sense to call the former two methods for any call of `set_time_shift`, including calls by users.
- 9:43 PM Changeset [1932:3cbfe0a457db] by
- Use `datetime` API instead of `time` API The `datetime` API is easier to use. Could be that this test code was written when `datetime` wasn't a part of the Python standard library.
- 9:17 PM Changeset [1931:834c3a213ba7] by
- Use `datetime` API instead of `time` API Using `datetime` usually is far less convoluted. The reason that `time` was used here is that this ftputil code likely was written before the `datetime` module was added to Python's standard library.
- 8:40 PM Changeset [1930:1c9ad5ef5579] by
- Add three todo items
- 8:37 PM Changeset [1929:ed7b9bb519bb] by
- Remove todo item on path-like arguments This has been implemented as ticket 119.
- 8:33 PM Changeset [1928:7e2299845b86] by
- Change `utc_local_time_shift` to `expected_time_shift` Replace the function `utc_local_time_shift` with `expected_time_shift`. The purpose of both functions is very similar, to set the constant `EXPECTED_TIME_SHIFT`. I changed the name because the time shift is now relative to UTC, not to the local time of the client. Therefore, the function old name would be confusing. ticket: 134
- 7:49 PM Changeset [1927:81bbc72efc93] by
- Adapt test to new definition of time shift The time shift is still server time minus client time, but the client time is expressed in UTC. A time shift of 0.0 means that the timestamps returned by the server are also in UTC. ticket: 134
- 7:40 PM Changeset [1926:225ad3bcdc07] by
- Use fractions consistently `minute` would already be a float because `second` is.
- 7:24 PM Changeset [1925:68fd6debe77c] by
- Clear cache if time shift changes If the time shift changes, all timestamps in the cache will be wrong with respect to the _new_ time shift. Depending on the cache, reusing the old timestamps may not be a problem, but in some cases it might be. Therefore stay on the safe side and clear the cache, sacrificing efficiency in favor of correct timestamps. At first sight, we could "correct" the cache entries by applying the difference between old and new time shift to the existing cache entries. However, I think the interactions in ftputil are already so complicated that I'd like to avoid any probably unnecessary optimizations. Also, the time shift would probably be set soon after creating the `FTPHost` instance, so anyway only relatively few cache entries would be affected.
Apr 10, 2020:
- 8:25 PM Changeset [1924:f4b90fa97634] by
- Update `set_time_shift` docstring Emphasize that the client time is UTC. This is consistent with the new calculation in `_Stat.parse_unix_time`. In previous versions of ftputil, the time shift was supposed to be the difference between the local server time (assumed from the timestamp on the server) and the local client time. However, in some circumstances the client time was retrieved in UTC (namely by `os.path.getmtime`), which was inconsistent with other places where the client time was assumed to be a local time. ticket: 134
- 8:18 PM Changeset [1923:7b4b21f5da09] by
- Subtract time shift only once The new code in `_Stat.parse_unix_time` returns the server time already corrected by the time shift. Therefore it's a bug to subtract the time shift again in `RemoteFile.mtime`. ticket: 134
- 4:30 PM Changeset [1922:da97ee1b9599] by
- Add `freezegun` dependency This is used in at least one unit test. This dependency is _only_ needed for testing, _not_ for normal library use.
- 4:29 PM Changeset [1921:4be05b9c21f3] by
- Test newer Python versions ftputil 4.x will no longer support Python 3.5.
- 4:28 PM Changeset [1920:b0227e74eaff] by
- Fix marker selection The marker has been renamed to `slow_test` a while ago.
- 4:24 PM Changeset [1919:e1f302aa89d0] by
- Use constant `unknown` instead of `None` Although `ftputil.stat.UNKNOWN_PRECISION` is indeed `None`, we're actually interested in the symbolic constant here.
- 4:05 PM Changeset [1918:012ebe07956d] by
- Use `utcnow` to match stat result The modification time in a stat result is UTC, not local time. ticket: 134
Apr 5, 2020:
- 10:13 PM Changeset [1917:ed871b3f42c4] by
- Format docstrings and comments to 80 chars width
- 9:57 PM Changeset [1916:a526dce5108f] by
- Assume server time without time shift is UTC By default, assume the timestamps in the FTP server's listings are in UTC. The user can still set a time shift in case the server doesn't use UTC timestamps. The reasons for assuming UTC are explained in ticket #134. Dealing with "only" UTC and the time shift makes the code a bit easier to handle because we don't need to consider mismatches between UTC and local time (let alone different local times on server and client). That said, we _may_ have time differences between server and client, but such a time difference should be solely covered by the time shift value. Especially tricky is the decision which year to choose for the timestamp if the directory line from the server doesn't contain a year value. This can't be solved clearly, so use a heuristics (see the code comments in `parse_unix_time`). ticket: 134
Mar 4, 2020:
- 4:05 PM Ticket #135 (test if_newer failing) created by
- in mock_ftplib.py, some file are set to Jan 19 2020, expecting in test …
Note: See TracTimeline
for information about the timeline view.
