fix(dumpkit): write plist dates to whole seconds so plistlib reads them (#1448)

[JarryShaw]

• Searched for similar pull requests

• Followed the coding style — pylint, mypy and isort run on the changed files; no new findings

• make test passes, and a test case covers the change — dumpkit leg 232/0, foundation leg 528/0, tests/integration/test_output_formats.py 14 passed, tests/project 419 passed; the three touched plist modules also pass on Python 3.10 (23 passed)

• Changelog entry — N/A — centralised in docs(changelog): shared 1.5.0 changelog — long-lived, merges last (#610, #616, #617, #618, #620) #657

• fix — corrects a defect

---

Closes #1448

dictdumper's PLIST._append_date writes .%fZ, which plist <date> does not admit. make_dumper now overrides it for PLIST writers, so the xml output (also PLIST) changes too. Aware values are converted to UTC and the fraction of the already microsecond-rounded datetime is dropped, as plistlib.dump does.

Precision: no key is added. Every reported timestamp already has an exact sibling: time_epoch/timestamp_epoch (a Decimal), or the raw ntp_timestamp/pmip_timestamp for the MH options. Checked over all 1660 dates in the 23 captures.

• plistlib.load on the 23 captures: 0/23 before → 23/23 after.
• json/tree reports of all 23 captures are byte-identical before and after. In plist/xml, only <date> lines change.
• 6 tests fail without the fix: the 4 new unit tests in test_plist_date_unit.py, test_plist_report_round_trips_through_plistlib (now un-skipped), and the dictdumper PLIST writer does not escape angle brackets, so a pseudo-member makes the dump unparseable #772 test test_the_plist_report_of_a_bytes_keyed_mapping_parses (now reads via plistlib.load). The pep.rst note is updated.
• Rebased on test: capture-driven parse→rebuild and dumper round trips (#1202) #1445: its KNOWN_FAILURES row for fix(dumpkit): plist output is unreadable by plistlib because timestamps carry fractional seconds #1448 in tests/dumpkit/test_capture_dump_runtime.py is removed, and that module passes.

[JarryShaw]

Verdict: GOOD TO GO at 5403616d6 (Sonnet cross-review on 4a2d70c09; the author ran on Opus).

• plistlib.load now succeeds on every capture's plist and xml dump: 44 of 44, where main fails all 44. Hand-built PCAP-NG files with if_tzone ±5h/+9h, epoch 0, year 5 and year 9999 all load too.
• Every date keeps its exact value. All 1660 <date>s have an exact sibling (time_epoch, timestamp_epoch, NTP/PMIP), with 0 mismatches under TZ=UTC, Asia/Tokyo and America/New_York.
• The naive-as-UTC branch is never hit by pcapkit itself. Every datetime it emits is already aware (frame.py:270, pcapng.py:1747, mh.py:4103).
• json/tree output is byte-identical to main on all captures.
• Tests fail without the fix: 6 fail with common.py taken from main.
• Neighbouring suites pass: the dumpkit leg is 232 OK, foundation 528 OK, tests/project 419 passed.
• What changed since the reviewed head (4a2d70c09 → 5403616d6): only tests and a docstring. plistlib.load(aware_datetime=...), which is Python 3.13+ and was the cause of the red 3.10–3.12 legs, was dropped. I re-ran the three touched modules: 23 passed. The worker also ran them on a real 3.10 interpreter: 23 passed.

Conflict with #1445: both PRs edit tests/integration/test_output_formats.py (the PlistRoundTripTests skip). Whichever lands second must also remove the #1448 KNOWN_FAILURES entry.

[github-actions]

Coverage: 89.51% (unit tier, Python 3.14, 2ab8bbe83, Unit Tests run success)

Package	Statements	Missed	Branches	Partial	Cover
pcapkit (top level)	104	4	20	4	93.55%
pcapkit/const	18795	968	2356	869	90.90%
pcapkit/corekit	2043	89	636	25	94.77%
pcapkit/dumpkit	242	2	88	2	98.79%
pcapkit/foundation	2648	98	930	48	94.80%
pcapkit/interface	112	7	40	5	92.11%
pcapkit/protocols	16805	219	4522	183	98.08%
pcapkit/toolkit	539	74	168	3	84.58%
pcapkit/utilities	429	4	122	4	98.55%
pcapkit/vendor	4409	2342	1006	157	43.25%

Per-file detail: the coverage-html artifact of this run.

[JarryShaw]

resolve conflicts

[JarryShaw]

On it. The worker is rebasing onto main (b14d676c5), keeping this PR's PlistRoundTripTests, and dropping the now-stale #1448 row from tests/dumpkit/test_capture_dump_runtime.py in the same commit. I'll re-verify the new head before re-granting the verdict.

[JarryShaw]

Verdict: GOOD TO GO at 2ab8bbe83, which is 5403616d6 rebased onto main (b14d676c5).

• Library code is unchanged: the pcapkit/ diff is line-for-line identical to the head the Sonnet review passed.
• Test changes:
  • The fix(dumpkit): plist output is unreadable by plistlib because timestamps carry fractional seconds #1448 KNOWN_FAILURES row is removed from tests/dumpkit/test_capture_dump_runtime.py, leaving the table empty.
  • The conflict in tests/integration/test_output_formats.py resolved to this PR's version, with no skip.
  • The stale comment in sections() is reworded. It still reads the plist with ElementTree, so the plistlib test has an independent reader to compare against.
• Re-run myself on this head: the dump runtime module, test_output_formats, the plist date tests and the escaping-regression tests give 29 passed, 1735 subtests.