[transfer] Fix date_imported to use a correct ISO 8601 date #8095
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #8095 +/- ##
=======================================
Coverage 94.45% 94.45%
=======================================
Files 1141 1141
Lines 98198 98198
=======================================
Hits 92757 92757
Misses 5441 5441
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Hi @mgorny! I've just tested this against AWS, and they actually return an epoch timestamp here - so I think we should do the same.
We have an existing utility method for that:
from moto.core.utils import unix_time
now = unix_time()
I don't know whether that affects 32-bit systems? If so, we may just have to disable the tests instead.
mgorny
force-pushed
the
fix-date-imported
branch
from
3bbc65d
to
18e6935
Compare
|
Sure, updated it to do that. It's also going to work on 32-bit arches, at least until 2038 (and then, everything else will fail too, so not an issue). |
mgorny
force-pushed
the
fix-date-imported
branch
from
18e6935
to
805b6f8
Compare
Fix `date_imported` key to use a proper UNIX timestamp rather than concatenated digits of an ISO-8501 date. Botocore expects the former rather than the latter, and interprets the latter it as UNIX timestamp. This can particularly be seen on systems with 32-bit time_t, where the resulting timestamp overflows (it would correspond to year 643378 today), and causes `tests/test_transfer/test_transfer.py` failures such as: ``` E RuntimeError: Unable to calculate correct timezone offset for "20240907201715" ``` When passing a correct timestamp, the relevant tests pass both on systems with 64-bit and 32-bit time_t (at least until 2038).
mgorny
force-pushed
the
fix-date-imported
branch
from
805b6f8
to
a4aace1
Compare
|
Thanks! |
|
This is now part of moto >= 5.0.14.dev70 |
Fix
date_importedkey to use a proper ISO 8601 format (with hyphens and colons) rather than concatenated numbers. Botocore expects the former rather than the latter, and when given a bare number it incorrectly interprets it as UNIX timestamp rather than%Y%m%d%H%M%Sdate.This can particularly be seen on systems with 32-bit time_t, where the resulting timestamp overflows (it would correspond to year 643378 today), and causes
tests/test_transfer/test_transfer.pyfailures such as:When using
%Y-%m-%d %H:%M:%Sformat, the relevant tests pass both on systems with 64-bit and 32-bit time_t.