Skip to content

Remove iso8601 dependency#2213

Open
waketzheng wants to merge 2 commits into
tortoise:developfrom
waketzheng:remove-iso8601
Open

Remove iso8601 dependency#2213
waketzheng wants to merge 2 commits into
tortoise:developfrom
waketzheng:remove-iso8601

Conversation

@waketzheng

Copy link
Copy Markdown
Contributor

Description

This removes the runtime dependency on iso8601 and replaces the fallback datetime parsing path with an internal parser based
on the Python standard library.

The new behavior is:

  • Prefer ciso8601.parse_datetime when the optional accel extra is installed.
  • Fall back to tortoise.timezone._parse_datetime when ciso8601 is unavailable.
  • Keep support for common formats accepted by ciso8601, including Z/z UTC suffixes, compact datetime strings, week dates,
    and ordinal dates such as 2020-230 and 2020230.
  • Reuse the same parser from field conversion and Oracle timestamp conversion.

This also updates the lockfile, removes iso8601 from tests, and adds a Windows CI smoke job for the accel extra now that
ciso8601 is no longer excluded on Windows.

Motivation and Context

iso8601 was only used as a fallback parser when ciso8601 was unavailable. That makes it a runtime dependency for a narrow
path that can now be covered by Python's standard library on Tortoise ORM's supported Python versions.

Keeping iso8601 has become hard to justify:

  • It adds an extra runtime dependency for all users, even though datetime parsing is the only reason it is needed.
  • Its maintenance cadence is slow, which increases long-term dependency risk for a core parsing path.
  • It duplicates functionality that is now largely available through datetime.fromisoformat().
  • It adds supply-chain and lockfile surface area for behavior we can implement locally in a small, explicit compatibility
    wrapper.
  • It creates a split fallback story: accelerated installs use ciso8601, while non-accelerated installs depend on a separate
    third-party parser with subtly different behavior.

This change keeps the fast path unchanged for users who install accel, while making the non-accelerated path self-contained
and easier to audit. The fallback parser intentionally preserves the common ciso8601 formats that matter for existing Tortoise
ORM behavior, so removing iso8601 should not narrow normal datetime input support.

The ciso8601 platform marker was also relaxed to allow Windows CPython installs. A Windows CI smoke job was added to verify
that the accel extra installs and that the accelerated parser is actually selected on Windows.

How Has This Been Tested?

Tested locally on macOS with Python 3.14.2.

Commands run:

.venv/bin/python -m pytest tests/fields/test_time.py
.venv/bin/python -m pytest tests/fields/test_time.py::test_parse_datetime_fallback tests/fields/
test_time.py::test_parse_datetime_uses_fallback_without_ciso8601 tests/fields/
test_time.py::test_parse_datetime_fallback_matches_ciso8601
.venv/bin/ruff check tortoise/timezone.py tests/fields/test_time.py
.venv/bin/mypy tortoise/timezone.py
uv lock --check --default-index https://pypi.org/simple

Results:

- tests/fields/test_time.py: 58 passed, 11 skipped
- Parser-specific tests: 20 passed
- Ruff: passed
- Mypy: passed
- Lockfile check: passed

Additional coverage added:

- Verifies fallback parser behavior directly.
- Verifies fallback import behavior when ciso8601 is unavailable.
- Verifies fallback parser matches ciso8601.parse_datetime for common supported datetime formats.
- Adds Windows CI smoke coverage for ciso8601 via the accel extra.

## Checklist:

- [x] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [ ] I have added the changelog accordingly.
- [x] I have read the CONTRIBUTING document.
- [x] I have added tests to cover my changes.
- [x] All new and existing tests passed.

@codspeed-hq

codspeed-hq Bot commented Jun 6, 2026

Copy link
Copy Markdown

Merging this PR will not alter performance

✅ 24 untouched benchmarks


Comparing waketzheng:remove-iso8601 (05786ff) with develop (c8ed5e9)

Open in CodSpeed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant