parse 1.22.3 - Timezone Offsets Survive strftime Time Only Results

The parse library shipped 1.22.3 on October 10, 2026. It is a single change release: parsed time values keep their timezone offsets when they go back through strftime formatting for time only results. If your ETL jobs parse timestamps and then reemit them, this fix matters.

The full release notes and downloads are on the GitHub release page.

parse is the inverse of format strings. You hand it a template like "{when:%H:%M:%S %z}" and a string, and it returns values typed against the format specifiers. It sits in the ingestion path of plenty of pipelines precisely because it handles messy text files where datetime.strptime would choke on surrounding noise.

The problem shows up in a narrow but real case. Parse a value with an explicit UTC offset, then format that parsed datetime back with a time only directive such as %H:%M:%S. Before 1.22.3 the offset information did not survive the round trip through strftime in the way callers expected, so normalized output could drift from the source material. In a dataset pipeline that means the same record reads differently before and after a republish step.

One pull request, PR #257 from xiehuanyi: “Preserve timezone offsets in strftime time only results,” merged as pull 257. That is the entire changelog between 1.22.2 and 1.22.3, per the compare view on GitHub.

The tradeoff profile is simple. Winners: anyone parsing %z style offsets and reformatting them, typical in log ingestion and open data ingest jobs. Losers: nobody should be, since the previous behavior was a silent data fidelity bug rather than a documented contract. If some downstream test asserted on the old lossy output, it will need updating, but that test was asserting a bug.

It is also the first contribution from the author of the fix, which is worth noting only because it means the change has had limited history soak; the release is tagged and out, so treat it as a low risk but lightly exercised patch.

No breaking changes are listed in the notes and there are no migration steps. The tag bumps a single behavior. If you pin parse==1.22.2 in a requirements file and you parse timestamps with offsets, the move to 1.22.3 is a one line change worth scheduling with your normal dataset validation checks, since output values may shift in places where the old code dropped offset information.

Not a prerelease. This is a regular tagged patch release.