Repository navigation
.NET 11 reads an hour of 24: 24:00:00 parses as 00:00:00 and T24:00:00 as the next day #286
Description
Problem
TimeOnly.TryParseExact("24:00:00", "HH:mm:ss") returns true and 00:00:00 on .NET 11, and DateTime.TryParseExact("2026-01-01T24:00:00", …) returns the next day's midnight; .NET 10 refuses both. IsoTemporal hands the element text to those, so on the 11 line TimeRange.ParseValue("24:00:00") returns midnight where 10.x throws FormatException (TemporalLiteralGrammarTests.Time_Rejects("24:00:00") fails on net11.0), TimeSet.Parse("{24:00:00}") is {00:00:00}, and [2026-01-01T24:00:00,…) is a different tsrange from what 10.x refuses.
PostgreSQL's time accepts 24:00:00 as a value TimeOnly cannot hold (docs/efcore.md says so), and never prints a timestamp that way. Silent on the 11 line only; no released version is affected.
Change
IsoTemporal refuses an hour of 24 before the BCL parse, for a time, a DateTime and a DateTimeOffset, so the grammar means the same on both lines. Rows for 24:00, 24:00:00.0, T24:00:00, 24:00 and T24:00:00Z in TemporalLiteralGrammarTests.
Found by the #103 retarget's first test run.
Activity
CaffeinatedCoder commentedon Oct 19, 2026
"No released version is affected" holds for the .NET 10 runtime only. Measured 2026-10-19 with the published 10.0.0 package, one
net10.0build run with--roll-forward Majoron .NET 11.0.0-rc.2:TimeSet.Parse("{24:00:00}", null)returns{00:00:00.0000000}, andDateTimeRange/DateTimeOffsetRangereadT24:00:00as the next day's midnight, where .NET 10.0.13 throwsFormatExceptionfor all three. Anet11.0application referencing the 10.x packages runs them on the .NET 11 BCL, so the 10.x line has this as a silent bug on that runtime: #300, parked under the backlog (#83) becausesilentships in a 10.x minor, never in the 10.0.1 patch.fix: refuse an hour of 24 in temporal text on the .NET 11 runtime too