gh-128584: Allow gzip mtime to be a datetime object

[gchqdev227]

Allows the mtime parameter of gzip.GzipFile and gzip.compress to be a datetime.datetime object.

• Issue: Allow gzip mtime to be a datetime object #128584

---

📚 Documentation preview 📚: https://cpython-previews--128589.org.readthedocs.build/

[ghost]

All commit authors signed the Contributor License Agreement.

[ZeroIntensity]

General triage comments. I'll dive into the actual implementation sometime soon.

[gchqdev227]

Hi @ZeroIntensity, thank you for reviewing the PR.

I've pushed a new commit which causes the relevant compress methods to raise a ValueError if the datetime object is not timezone-aware. This is to address security concerns where naive datetimes can lead to informational leakage in web servers and similar contexts: see here for one such example. This also enforces the RFC.

I'm highlighting this as it's an additional change not mentioned in the original issue or PR description. If you don't think it's appropriate for this PR then please let me know and I'll revert the commit.

[ZeroIntensity]

I think that makes sense. FYI, tests are failing on Windows.

[gchqdev227]

Hi @ZeroIntensity, is this ready to merge please?

[ZeroIntensity]

Sorry, I don't know enough about this part of the codebase to do a thorough review, nor do I have the sufficient permissions to merge this :(

@picnixz, would you mind taking a look?

[picnixz]

I'm leaving until Friday, I can take a look at that time.

[picnixz]

@ZeroIntensity I couldn't find the PR to look at it before so in the future, if you want my review on a PR, just outright request it, it's fine for me!

[picnixz]

Serhiy hinted that this would create a dependency between datetime and gzip (#128584 (comment)). I also agree that it's probably cleaner for the caller to call .timestamp() before instead of doing it at the library level.

An alternative would however to use duck-typing. Instead of checking for datetime instances, we could check for any instance having a callable timestamp() method:

elif callable(getattr(mtime, 'timestamp', None)):
    mtime = mtime.timestamp()

However, this would be again quite niche and could open other holes. What about other conversion methods? etc and perhaps we need more checks. So, considering this, I think it's fine to keep it as is.

What I may however think of is that we could have datetime objects implement __int__ so that int(mtime) would be int(mtime.timestamp()) for datetime objects. But this is something orthogonal and I'm not sure that it makes sense (also should we assume UTC timezone for that? or something else?)

Thus, I suggest closing this one unless @serhiy-storchaka thinks that the protocol check is fine and/or implementing __int__ for timestamp conversion on datetime objects is a good idea.