DeVaNsHk72 commented on code in PR #44391:
URL: https://github.com/apache/superset/pull/44391#discussion_r4053837369
##########
superset/utils/core.py:
##########
@@ -2220,12 +2220,31 @@ def apply_max_row_limit(
return max_limit
+def write_zip_entry(bundle: ZipFile, filename: str, contents: bytes) -> None:
+ """Add a file to an open ZIP bundle, stamped with the current local time.
+
+ ``ZipFile.open(name, "w")`` falls back to the 1980-01-01 DOS epoch, which
+ extractors surface as a bogus (Windows Explorer) or empty (7-Zip)
+ modification date on every extracted file. Passing an explicit ``ZipInfo``
+ gives the entry the time the export was generated instead.
+ """
+ info = ZipInfo(filename=filename, date_time=datetime.now().timetuple()[:6])
Review Comment:
I do not think this one holds either.
`ZipInfo` only rejects years before 1980, and it accepts years past 2107
without raising (`ZipInfo('a', date_time=(2200,1,1,0,0,0))` is fine on 3.11).
So the failure mode needs a system clock set before 1980, at which point an
export archive is not the first thing to worry about.
It is also not new behaviour from this PR. `writestr(filename, contents)` on
master already stamps `time.localtime()` on every entry, for example in
superset/dashboards/api.py:1703, so the same clock would have produced the same
result before this change. Adding a clamp here would guard one call site
against a condition the rest of the codebase does not guard against.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
