ZipFile.open() should not ignore compression, new file should default to today rather than 1980

Bug report

Bug description:

When streaming, writing to a zip file, it internally creates a ZipInfo object without explicitly setting date_time, causing a timestamp of 1980 to be used. I believe in almost all cases, using the current timestamp makes more sense, I rarely zip files from 1980. To work around that issue, I create the ZipInfo object myself and pass it to the open() method, which causes another bug where the specified compression is ignored and the file is simply stored.

After some minor investigation, I've found issue #113971 which at least hinted towards what I now use as workaround but otherwise didn't fix this:

Today people pass ZipInfo instances into APIs that accept them such as ZipFile.writestr() in order to control how individual items are put into a zip archive as such ...
zip_info.compress_type

So you'd create a new ZipFile specifying a compression but after open(), you're just storing uncompressed:

zip_info = zipfile.ZipInfo("file")
# zip_info.compress_type, ._compresslevel are wrong
zip_file.open(zip_info, mode="w", force_zip64=True)

In other words, I expect that:
a) when using open("file"...), it should use the current time as mtime by default
b) when creating a ZipInfo object to specify another date or another setting for the new file, it should inherit the previously configured compression
Both assumptions are wrong, which is what I'm suggesting to fix.

Here's a reproducer and I'll add a PR as suggested fix...
https://gist.github.com/c0xc/b54c005b296cdf6378ce65dd4aff3fe7

CPython versions tested on:

3.11, CPython main branch

Operating systems tested on:

Linux

Linked PRs

• gh-121405

リンクされた再現コードと、レポートで説明されている ZipFile.open() および ZipInfo の動作から始めてください。ZipInfo オブジェクトが指定された場合に、新しいエントリの書き込みでデフォルトのタイムスタンプと圧縮がどのように決定されるかを確認してください。期待されるタイムスタンプと設定された圧縮動作の両方がカバーされれば完了としますが、この issue ではリンクされた PR gh-121405 が指摘されています。