Repository navigation
Conversation
isoformat() adds a seconds field for a UTC offset that is not a whole
number of minutes (e.g. the LMT offsets zoneinfo gives for historical
dates), and the '+00:00' -> 'Z' replacement in item() could also hit
the start of such an offset ('Z:30'). TOML offsets are HH:MM, so the
output could not be parsed by tomlkit or tomllib. Write such values as
the same instant in UTC in item(), DateTime() and DateTime._new().
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
item()anddumps()render adatetimewithisoformat(). When the UTC offset is not a whole number of minutes,isoformat()adds a seconds field (-00:44:30), and for an offset such as+00:00:30the"+00:00"to"Z"replacement initem()turns it intoZ:30. TOML offsets areHH:MM, so neither tomlkit nortomllibcan read the output back.zoneinfogives these offsets (local mean time) for dates before a zone's first transition:This PR adds
_format_datetime(), which writes such a value as the same instant in UTC (1960-01-01T12:44:30Zabove) and leaves whole-minute offsets unchanged.item(),DateTime()withoutraw, andDateTime._new()(used byreplace(),astimezone()and arithmetic) all go through it. The item keeps its original fields andtzinfo; only the written text changes, and the parsed value compares equal to the original. This is in the same spirit as #613, which made tz-awaretimevalues render as valid TOML. If you would rather raiseValueErrorfor these offsets, I can switch to that.Tests:
tests/test_items.pycover offsets of +30 s, +1 h 0 min 1 s, -44 min 30 s and 1 microsecond throughitem(),dumps(),astimezone()andreplace(), and check that the item keeps its fields. All 5 fail onmasterand pass with this change.toml-testsubmodule: 1229 passed (1224 before, plus the 5 new tests), Python 3.11 only.Africa/Monroviaexample above, read back withtomllib, now gives a value equal to the original.checkandformat --check): clean. mypy 1.19.1 (the pinned version): the same 33 errors before and after, none in the changed lines.No linked issue.
Duplicate Check
DateTime.astimezone()and reflected addition, not how the raw string is built. Reject UTC offsets TOML cannot write instead of emitting invalid output #598 (closed on 2026-09-08 without review; the author account no longer exists) proposed raisingValueErrorfor these offsets; this PR writes them as UTC instead.Agent Drafting Metadata
dumps()thentomllib.loads()) in an AI-assisted scan of open-source projects. The agent wrote the fix, the tests, the changelog entry and this description, and ran the checks listed above.