Repository navigation
10.x on the .NET 11 runtime reads an hour of 24: {24:00:00} parses as {00:00:00} and T24:00:00 as the next day #300
Description
Problem
IsoTemporal hands an element's text to TimeOnly.TryParseExact, DateTime.TryParseExact and DateTimeOffset.TryParseExact. .NET 11 accepts an hour of 24 there where .NET 10 refuses it (#286). The 10.x packages target net10.0, but a net11.0 application that references them runs them on the .NET 11 BCL, so the shipped 10.0.0 answers differently by runtime.
Measured 2026-10-19 with the published 10.0.0 package: one net10.0 build of a probe, run on .NET 10.0.13 and, with --roll-forward Major, on .NET 11.0.0-rc.2:
| Call | .NET 10.0.13 | .NET 11.0.0-rc.2 |
|---|---|---|
TimeSet.Parse("{24:00:00}", null) |
FormatException |
{00:00:00.0000000} |
TimeRange.Parse("[23:00:00,24:00:00)", null) |
FormatException |
FormatException (24:00:00 became 00:00:00, below the lower bound) |
DateTimeRange.Parse("[2026-01-01 00:00:00,2026-01-01T24:00:00)", null) |
FormatException |
[2026-01-01T00:00:00.0000000,2026-01-02T00:00:00.0000000) |
DateTimeOffsetRange.Parse("[2026-01-01 00:00:00Z,2026-01-01T24:00:00Z)", null) |
FormatException |
[2026-01-01T00:00:00.0000000+00:00,2026-01-02T00:00:00.0000000+00:00) |
PostgreSQL's time accepts 24:00:00 as a value TimeOnly cannot hold, and never prints a timestamp that way. Silent, on the .NET 11 runtime: #286's "no released version is affected" holds for the .NET 10 runtime only.
Change
The #286 fix ported to release/10.x: IsoTemporal refuses an hour of 24 before the BCL parse, for a time, a DateTime and a DateTimeOffset, with the TemporalLiteralGrammarTests rows (24:00, 24:00:00.0, T24:00:00, 24:00, T24:00:00Z). On the .NET 10 runtime nothing changes; on .NET 11, {24:00:00} throws where it returned midnight.
Release
silent, so a minor: ships in 10.1.0 (epic #296; decided 2026-10-19 to make the first 10.x release a minor so this rides along). The fix PR adds, at the top of the ## [10.1.0] section of the root and core changelogs, the ### Changed answers row linking this issue and the ## Changed answers in 10.1.0 section it adds to docs/migration.md (how to find the calls whose answer changed: any literal or JSON element with an hour of 24, which .NET 11 accepted and 10.1.0 refuses; on the .NET 10 runtime nothing changes). pr-hygiene.sh refuses a silent PR without that row and reads the version from the branch, so the PR comes after #301 step 1 has merged. 10.x CI can see the defect only by running the net10.0 test suites on a .NET 11 runtime (roll-forward), which the newest-toolchain leg of #297 could add; TemporalLiteralGrammarTests.Time_Rejects("24:00:00") is the test that fails there today.
Activity
fix: refuse an hour of 24 in temporal text on the .NET 11 runtime too
CaffeinatedCoder commentedon Oct 19, 2026
Fix ported in #308 against
release/10.x(after #305 and #306 merged, so it is not stacked). Proved on the .NET 11.0.0-rc.2 runtime by running thenet10.0core test assembly under that host with--roll-forward Major: without the fixTime_Rejects("24:00:00")and the six new rows fail (7 of 115), with it all 115 pass, and the whole core project passes on 10.0.13 and 11.0.0-rc.2 alike. Note for #297:dotnet testwithDOTNET_ROOTset does not move the test host, because VSTest launches it from the muxer that runsvstest.console; runvstest.console.dllunder the target host instead. This issue is closed by hand after the merge.CaffeinatedCoder commentedon Oct 19, 2026
Fixed on
release/10.xby PR #308 (merge commit b74064a, 2026-10-19), with the### Changed answersrow and the## Changed answers in 10.1.0migration section. Closed by hand:Closesacts only onmain, where the fix arrived with PR #292 (#286).Merge release/10.x into fix/299-aot-set-tostring-net11-sdk
CaffeinatedCoder commentedon Oct 19, 2026
Measured 2026-10-19 on
release/10.xat 3ed738e: the whole 10.1.0 candidate passes on the .NET 11.0.0-rc.2 runtime (roll-forward), and withStartsWithHour24stripped, 7 of the 115 grammar rows fail there and none on .NET 10. CI onrelease/10.xstill can't see this; the leg that would is #324.