Pydantic Datetime validation works incorrectly after

The Fix

pip install pydantic==2.6.2

Based on closed pydantic/pydantic issue #8736 · PR/commit linked

Production note: Most teams hit this during upgrades or environment changes. Roll out with a canary and smoke critical endpoints (health, OpenAPI/docs) before 100%.

Jump to Verify Open PR/Commit

@@ -59,7 +59,9 @@ types:
     * `str`; the following formats are accepted:
         * `YYYY-MM-DD[T]HH:MM[:SS[.ffffff]][Z or [±]HH[:]MM]`
+        * `YYYY-MM-DD` is accepted in lax mode, but not in strict mode
         * `int` or `float` as a string (assumed as Unix time)
+    * [`datetime.date`][] instances are accepted in lax mode, but not in strict mode

repro.py

async def test_pydantic_breakage():
    @dataclass
    class SharedTimeRangeParams:
        start_time: datetime = Path(..., description="Query timerange start UTC date-time", examples=["2017-07-21T17:32:28Z"])
        end_time: datetime = Path(..., description="Query timerange end UTC date-time", examples=["2017-07-21T17:32:28Z"])

    app = FastAPI()

    @app.get("/some/path/{start_time}/{end_time}")
    async def handler(time_range: SharedTimeRangeParams = Depends()):
        return {"start": time_range.start_time, "end": time_range.end_time}

    client = TestClient(app)
    # Ok
    res = await client.get("/some/path/2024-01-01T00:00:00Z/2024-01-02T23:59:59.999Z")
    assert res.json() == {"start": "2024-01-01T00:00:00+00:00", "end": "2024-01-02T23:59:59.999000+00:00"}

    # Broken in 2.6
    res = await client.get("/some/path/2024-01-01/2024-01-02")
    # In 2.6 end is at midnight which doesn't make sense for API usage in the range param
    # assert res.json() == {"start": "2024-01-01T00:00:00+00:00", "end": "2024-01-02T00:00:00+00:00"}

    # This doesn't work in 2.6 anymore
    assert "Input should be a valid datetime" in res.json()["detail"][0]["msg"]

verify

Re-run the minimal reproduction on your broken version, then apply the fix and re-run.

fix.md

Option A — Upgrade to fixed release\npip install pydantic==2.6.2\nWhen NOT to use: This fix is not applicable if strict datetime validation is not desired.\n\nOption C — Workaround\nfor you too: if we fix the timezone inference bug then you could use `AwareDatetime` on this field. It would force your users to add timezone information, but it would also avoid this coercion.\nWhen NOT to use: This fix is not applicable if strict datetime validation is not desired.\n\n

Why This Fix Works in Production

Trigger: Datetime validation works incorrectly after Pydantic 2.6 with range parametrized APIs in FastAPI
Mechanism: Minor documentation updates addressing datetime validation issues in Pydantic 2.6, including guidance on using strict mode.
Why the fix works: Minor documentation updates addressing datetime validation issues in Pydantic 2.6, including guidance on using strict mode. (first fixed release: 2.6.2).

Production impact:

If left unfixed, the same config can fail only in production (env differences), causing startup failures or partial feature outages.

Why This Breaks in Prod

Triggered by an upgrade/regression window: 2.6–59.999000 breaks; 2.6.2 is the first fixed release.
Shows up under Python 3.12 in real deployments (not just unit tests).
Production symptom (often without a traceback): Datetime validation works incorrectly after Pydantic 2.6 with range parametrized APIs in FastAPI

Proof / Evidence

GitHub issue: #8736
Fix PR: https://github.com/pydantic/pydantic/pull/8824
First fixed release: 2.6.2
Affected versions: 2.6–59.999000
Reproduced locally: No (not executed)
Last verified: 2026-02-09
Confidence: 0.85
Did this fix it?: Yes (upstream fix exists)
Own content ratio: 0.42

Discussion

High-signal excerpts from the issue thread (symptoms, repros, edge-cases).

Jump to Sources Open on GitHub

“@Kxnr inference of timezone is a separate question to coercion of date strings to midnight datetimes. However, I can reproduce and agree that's a bug.…”

@davidhewitt · 2024-02-08 · source

“We have implemented TypeAdapter.validate_strings which we believe is the correct solution for FastAPI to adopt in this case”

@davidhewitt · 2024-02-06 · source

“Putting this here as a reference for others in the future:”

@sydney-runkle · 2024-02-15 · source

“For context, Markus is my colleague so there's only one team having this problem 🙂 If you enable strict mode, the # Ok case will…”

@miikka · 2024-02-06 · source

Failure Signature (Search String)

Datetime validation works incorrectly after Pydantic 2.6 with range parametrized APIs in FastAPI
How do we block this bad behaviour in all our APIs (in context of range usage) with Pydantic 2.6? This seems to be no FastAPI issue as only change we did was trying out Pydantic

Copy-friendly signature

signature.txt

Failure Signature
-----------------
Datetime validation works incorrectly after Pydantic 2.6 with range parametrized APIs in FastAPI
How do we block this bad behaviour in all our APIs (in context of range usage) with Pydantic 2.6? This seems to be no FastAPI issue as only change we did was trying out Pydantic 2.6.

Error Message

Signature-only (no traceback captured)

error.txt

Error Message
-------------
Datetime validation works incorrectly after Pydantic 2.6 with range parametrized APIs in FastAPI
How do we block this bad behaviour in all our APIs (in context of range usage) with Pydantic 2.6? This seems to be no FastAPI issue as only change we did was trying out Pydantic 2.6.

Minimal Reproduction

repro.py

async def test_pydantic_breakage():
    @dataclass
    class SharedTimeRangeParams:
        start_time: datetime = Path(..., description="Query timerange start UTC date-time", examples=["2017-07-21T17:32:28Z"])
        end_time: datetime = Path(..., description="Query timerange end UTC date-time", examples=["2017-07-21T17:32:28Z"])

    app = FastAPI()

    @app.get("/some/path/{start_time}/{end_time}")
    async def handler(time_range: SharedTimeRangeParams = Depends()):
        return {"start": time_range.start_time, "end": time_range.end_time}

    client = TestClient(app)
    # Ok
    res = await client.get("/some/path/2024-01-01T00:00:00Z/2024-01-02T23:59:59.999Z")
    assert res.json() == {"start": "2024-01-01T00:00:00+00:00", "end": "2024-01-02T23:59:59.999000+00:00"}

    # Broken in 2.6
    res = await client.get("/some/path/2024-01-01/2024-01-02")
    # In 2.6 end is at midnight which doesn't make sense for API usage in the range param
    # assert res.json() == {"start": "2024-01-01T00:00:00+00:00", "end": "2024-01-02T00:00:00+00:00"}

    # This doesn't work in 2.6 anymore
    assert "Input should be a valid datetime" in res.json()["detail"][0]["msg"]

Environment

Python: 3.12
Pydantic: 2.6

What Broke

APIs fail to validate datetime ranges, leading to incorrect data processing.

Fix Options (Details)

Option A — Upgrade to fixed release Safe default (recommended)

pip install pydantic==2.6.2

When NOT to use: This fix is not applicable if strict datetime validation is not desired.

Use when you can deploy the upstream fix. It is usually lower-risk than long-lived workarounds.

Option C — Workaround Temporary workaround

for you too: if we fix the timezone inference bug then you could use `AwareDatetime` on this field. It would force your users to add timezone information, but it would also avoid this coercion.

When NOT to use: This fix is not applicable if strict datetime validation is not desired.

Use only if you cannot change versions today. Treat this as a stopgap and remove once upgraded.

Fix reference: https://github.com/pydantic/pydantic/pull/8824

First fixed release: 2.6.2

Last verified: 2026-02-09. Validate in your environment.

When NOT to Use This Fix

This fix is not applicable if strict datetime validation is not desired.

Verify Fix

verify

Re-run the minimal reproduction on your broken version, then apply the fix and re-run.

Did This Fix Work in Your Case?

Quick signal helps us prioritize which fixes to verify and improve.

Prevention

Add a CI check that diffs key outputs after upgrades (OpenAPI schema snapshots, JSON payload shapes, CLI output).
Upgrade behind a canary and run integration tests against the canary before 100% rollout.

Version Compatibility Table

Version	Status
2.6	Broken
59.999000	Broken
2.6.2	Fixed

Related Issues

No related fixes found.

Cluster: pydantic:configuration-error Pydantic hub Pydantic best practices All hubs All clusters

Related clusters: Data consistency OpenAPI schema Serialization

Sources

We don’t republish the full GitHub discussion text. Use the links above for context.

Pydantic Datetime validation works incorrectly after Pydantic 2.6 with range parametrized APIs in (Fix)