feat(core): widen the date/time parse grammar to .NET's (#1929 rows 1 and 3)

Decided by the user on 2026-08-18: widen all four of #1929's recorded respects.
Row 2 (a fractional second at 100-ns precision) already landed with rows 5-6 on
2026-08-01. Row 4 is the DateTimeKind and ParseExact surface and stays open as
#1941 and #1939. This is rows 1 and 3.

  Row 1  the MONTH and DAY admit one or two digits, so "2024-6-15" parses.
  Row 3  the OFFSET is .NET's ParseTimeZone grammar, so "+8", "+2:5", "+800"
         and "+0800" join "+02:05".

It is a PURE WIDENING. No string that parsed before parses differently or fails
now, so there is no source break, no signature change, no layout change and
nothing for a caller to migrate -- only a note that text .NET accepts is now
accepted here too. Landed under SA-5.

Both halves are transcribed, not guessed.

  * .NET's lexer types a digit run of one or two as a NumberToken and three or
    more as a YearNumberToken (Globalization/DateTimeParse.cs:5593-5605), so
    "2024-6-15" produces exactly the token sequence "2024-06-15" produces and
    reaches the same year-month-day terminal state.

  * ParseTimeZone (DateTimeParse.cs:530-556) reads ONE digit run after the sign:
    length 1-2 is an hour, optionally followed by ':' and a 1-2 digit minute;
    length 3-4 is split `value / 100` and `value % 100`. That integer split is
    WHY "+800" and "+0800" agree, and why "+205" means 125 minutes. A minute
    field of 60 or more is rejected, which is .NET's only check there
    (DateTimeParse.cs:565-568).

Two stops are deliberate and both are pinned.

  * The YEAR is not widened. .NET would read a short one through
    Calendar.ToFourDigitYear, whose century window is culture state this port has
    no way to carry, so "24-06-15" stays a failure rather than silently landing in
    a century nobody chose.

  * The +/-14h bound stays on DateTimeOffset and does NOT move into the shared
    grammar, because that is where .NET puts it: ParseTimeZone permits an hour up
    to 99 and the MinOffset/MaxOffset test runs later, at the two sites that
    actually STORE an offset (DateTimeParse.cs:2777,2875). System::DateTime parses
    an offset and discards it -- it has no DateTimeKind -- so it must not inherit a
    bound on a value it never keeps. DateTime::TryParse("...+99") succeeds and
    DateTimeOffset::TryParse("...+99") fails, and one test pins both halves of that
    sentence.

THE WIDENING FORCED A STRUCTURAL REPAIR THE TICKET DID NOT NAME.
DateTimeOffset::TryParse copied its input into a std::string, searched for a '+' or
'-' starting at CHARACTER 10, and handed the prefix to DateTime::TryParse. That
split is correct only while the date part is exactly ten characters wide, and
"2024-6-5" is eight -- so the search was about to start inside the date, or, for a
bare short date, past the end, which the `input.size() < 10` precheck was quietly
standing in for. The three doors now share one grammar in
System/detail/DateTimeTextScanner.hpp. They had drifted apart precisely because
they did not.

Ten existing pins are inverted in place, six cases added:
SharpRuntimeTests_Core_Base 6,019 -> 6,025. Two of the inverted ones are worth
naming. Ccf002_UnpaddedOffsetRejectionIsANarrowingNotAParityFix recorded that
#1879's rejection of "+2:5" was a NARROWING and not a parity fix, since .NET reads
it as 125 minutes -- the value this port already produced. It now pins the
agreement itself, which is what it was always about.

Nine mutations, all caught: month/day back to two digits (shared grammar, and
DateOnly's own copy, separately); dropping the minute<60 check; swapping the
hour/minute split of a 3-4 digit run; treating a 3-digit run as an hour;
ignoring the minus sign; moving the +/-14h bound into the shared grammar;
restoring the `size() < 10` precheck; letting the offset run reach five digits;
widening the year to 1-4 digits.

Downstream, measured per SA-2 condition 5: neither cna nor mobile-eggbert calls
DateTime/DateTimeOffset/DateOnly Parse or TryParse at all -- zero sites in both.
Neither repository was modified. A widening could not have changed their answers
in any case.

Gate: 17,296 run, 17,296 passed, 0 failed, 0 skipped across 38 executables,
GREEN, confirmed by two consecutive full runs.

docs/Migration-DateTimeGrammarWidening.md

Author: robertvokac

CLAUDE.md

@@ -0,0 +1,98 @@
+<!-- SPDX-License-Identifier: MIT -->
+<!-- Copyright (c) Robert Vokac and contributors -->
+
+# Migration — the date/time parse grammar widens to .NET's (ticket #1929)
+
+*2026-08-18.* `System::DateTime`, `System::DateTimeOffset` and `System::DateOnly` now accept a
+**one- or two-digit month and day**, and all three accept .NET's full **time-zone offset**
+grammar rather than a fixed `±HH:MM`.
+
+**This is a pure widening.** No string that parsed before parses differently or fails now, so
+there is no source break, no signature change, no layout change, and nothing to migrate. This
+note exists because text .NET accepts is now accepted here too, and a reader should know which
+text that is.
+
+Decided by the user on 2026-08-18, on ticket #1929's four recorded respects. Landed under
+`docs/StandingApprovals.md` SA-5 (derived from the reference, never guessed).
+
+---
+
+## 1. What is newly accepted
+
+| Input | Was | Is |
+|---|---|---|
+| `"2024-6-15"` | rejected | 15 June 2024 |
+| `"2024-06-5"` | rejected | 5 June 2024 |
+| `"2024-6-5T1:2:3-05:00"` | rejected | that instant at −05:00 |
+| `"…+8"` / `"…-8"` | rejected | ±8 h |
+| `"…+08"` | rejected | +8 h |
+| `"…+2:5"` | rejected | **125 min** — 2 h 05 m |
+| `"…+02:5"`, `"…+2:05"` | rejected | 125 min |
+| `"…+800"`, `"…+0800"` | rejected | +8 h |
+| `"…+205"`, `"…+0205"` | rejected | 125 min |
+| `"…-0530"` | rejected | −330 min |
+| everything that parsed before | — | **the identical value** |
+
+## 2. What is still rejected, and why
+
+| Input | Why |
+|---|---|
+| `"24-06-15"`, `"204-06-15"` | the year is exactly four digits — see §4 |
+| `"2024-006-15"`, `"2024-06-015"` | a field is at most two digits |
+| `"2024 -06-15"`, `"2024-06- 15"` | internal whitespace is grammar, and only the **outer** boundary is trimmed (#1929 row 5) |
+| `"…+2:60"`, `"…+0860"` | a minute field of 60 or more — .NET's own check, `DateTimeParse.cs:565-568` |
+| `"…+12345"` | a run of five digits is not an offset |
+| `"…+"`, `"…+2:"` | a sign or a colon with nothing after it |
+| `"…+02:00junk"` | the string must be consumed in full (#1879) |
+| `"June 15 2024"` | month names and culture patterns remain out of scope |
+
+## 3. Where each rule comes from
+
+Both halves are transcribed, not invented.
+
+**The date.** .NET's lexer classifies a run of one or two digits as a `NumberToken` and a run of
+three or more as a `YearNumberToken` (`Globalization/DateTimeParse.cs:5593-5605`). `"2024-6-15"`
+therefore produces exactly the token sequence `"2024-06-15"` produces — year, number, number — and
+reaches the same year-month-day terminal state. .NET accepts it; this port now does too.
+
+**The offset.** `ParseTimeZone` (`DateTimeParse.cs:530-556`) reads one digit run after the sign:
+
+* length **1 or 2** — that is the hour, and a `':'` may follow with a **1- or 2-digit** minute;
+* length **3 or 4** — the hour is `value / 100` and the minute is `value % 100`;
+* anything else fails.
+
+That integer split is why `"+800"` and `"+0800"` agree, and why `"+205"` means 125 minutes.
+
+## 4. Two deliberate stops
+
+**The year is not widened.** .NET would read a one- or two-digit year through
+`Calendar.ToFourDigitYear`, whose century window is culture state (`TwoDigitYearMax`) that this
+port has no way to carry. A short year stays a failure rather than silently landing in a century
+nobody chose.
+
+**The ±14 h bound stays on `DateTimeOffset` and does not move into the shared grammar.** That is
+where .NET puts it: `ParseTimeZone` permits an hour up to 99, and the
+`DateTimeOffset.MinOffset`/`MaxOffset` test runs later, at the two sites that actually store an
+offset (`DateTimeParse.cs:2777,2875`). `System::DateTime` parses an offset and **discards** it —
+it has no `DateTimeKind` (`docs/DateTimeValidationBoundaryPlan.md` §16.4) — so it must not inherit
+a bound on a value it never keeps. `DateTime::TryParse("…+99")` succeeds and
+`DateTimeOffset::TryParse("…+99")` fails, and a test pins both halves of that sentence.
+
+## 5. One structural change worth knowing about
+
+`DateTimeOffset::TryParse` used to copy its input into a `std::string`, search for a `'+'` or
+`'-'` **starting at character 10**, and hand the prefix to `DateTime::TryParse`. That split is
+correct only while the date part is exactly ten characters wide. Widening the month and day makes
+`"2024-6-5"` eight characters, so the search was about to start inside the date — or, for a bare
+short date, past the end, which the `input.size() < 10` precheck was quietly standing in for.
+
+The three doors now share one grammar in
+`modules/core/include/System/detail/DateTimeTextScanner.hpp`. They had drifted apart precisely
+because they did not.
+
+## 6. Downstream, measured
+
+Neither `cna` nor `mobile-eggbert` calls `DateTime::Parse`, `DateTime::TryParse`,
+`DateTimeOffset::Parse`/`TryParse` or `DateOnly::Parse`/`TryParse` at all — **zero sites in
+both**. Neither repository was modified. Since the change is a widening, even a caller that did
+parse dates would see no existing input change its value.

docs/Migration-DateTimeGrammarWidening.md

@@ -26,9 +26,11 @@
  * outside `int` by never reading more digits than fit.
  *
  * Deliberately **not** a general lexer: the port implements a narrow ISO-8601
- * subset by prior decision (`DateTime.hpp`, `TimeOnly.hpp`), and widening it is
- * new API surface, not a validation repair
- * (`docs/DateTimeValidationBoundaryPlan.md` §16.4).
+ * subset by prior decision (`DateTime.hpp`, `TimeOnly.hpp`). Ticket **#1929**
+ * (decided 2026-08-18) widened four respects of that subset to .NET's grammar --
+ * see `takeDateTimeParts` and `takeUtcOffsetMinutes` below -- but the subset is
+ * still a subset: no month names, no culture patterns, no two-digit year, and no
+ * `ParseExact` (`docs/DateTimeValidationBoundaryPlan.md` §16.4).
  */
 namespace System::detail {
 
@@ -74,7 +76,7 @@ class DateTimeTextScanner {
      * whole point of not using `std::sscanf`. Consumes nothing and returns
      * @c false unless at least @p minDigits digits are available; stops after
      * @p maxDigits so the accumulated value cannot overflow @c int (callers pass
-     * at most 4).
+     * at most 7).
      *
      * @param minDigits  Fewest digits that make the field well-formed.
      * @param maxDigits  Most digits the field may hold (<= 9).
@@ -106,4 +108,126 @@ class DateTimeTextScanner {
     std::size_t      index_ = 0;
 };
 
+/**
+ * @brief The calendar and clock fields one date/time string carries.
+ *
+ * `hasTime` distinguishes a bare date from one whose clock fields are all zero,
+ * which the parsers do not need but a caller reading this struct might.
+ */
+struct DateTimeParts {
+    int  year          = 0;
+    int  month         = 0;
+    int  day           = 0;
+    int  hour          = 0;
+    int  minute        = 0;
+    int  second        = 0;
+    int  fractionTicks = 0;
+    bool hasTime       = false;
+};
+
+/**
+ * @brief Consumes this port's ISO-8601 date-and-optional-time prefix.
+ *
+ * @verbatim
+ *     yyyy '-' M{1,2} '-' d{1,2}
+ *        [ (' '|'T') H{1,2} ':' m{1,2} ':' s{1,2} [ '.' f{1,7} ] ]
+ * @endverbatim
+ *
+ * Ticket #1929 rows 1-2 (decided 2026-08-18) widened the **month and day** to one
+ * or two digits, matching .NET: its lexer classifies a run of one or two digits as
+ * a `NumberToken` and three or more as a `YearNumberToken`
+ * (`Globalization/DateTimeParse.cs:5593-5605`), so `"2024-6-15"` reaches the same
+ * year-month-day terminal state that `"2024-06-15"` does. The **year** stays
+ * exactly four digits: that is this port's ISO subset, and a two-digit year would
+ * pull in `Calendar.ToFourDigitYear`'s culture-dependent century window.
+ *
+ * The fraction is read at 100-ns precision because `DateTime` is tick-based;
+ * `.1234567` keeps all seven digits, and an eighth is rejected rather than read as
+ * a prefix.
+ *
+ * Defined once here because three doors share the grammar. When they held their
+ * own copies they drifted: `DateTimeOffset` located its offset by scanning for a
+ * sign from **character 10**, which a one-digit month or day makes wrong.
+ *
+ * @param scanner Cursor to read from; consumes nothing on failure only insofar as
+ *                each field is individually atomic — a caller that needs to retry
+ *                should construct a fresh scanner.
+ * @param parts   Receives the fields that were present.
+ * @return @c true when the whole prefix is well-formed.
+ */
+[[nodiscard]] inline bool takeDateTimeParts(DateTimeTextScanner& scanner,
+                                            DateTimeParts&       parts) noexcept {
+    if (!scanner.takeDigits(4, 4, parts.year) || !scanner.take('-') ||
+        !scanner.takeDigits(1, 2, parts.month) || !scanner.take('-') ||
+        !scanner.takeDigits(1, 2, parts.day))
+        return false;
+
+    if (scanner.take(' ') || scanner.take('T')) {
+        if (!scanner.takeDigits(1, 2, parts.hour) || !scanner.take(':') ||
+            !scanner.takeDigits(1, 2, parts.minute) || !scanner.take(':') ||
+            !scanner.takeDigits(1, 2, parts.second))
+            return false;
+        parts.hasTime = true;
+        if (scanner.take('.')) {
+            int digits = 0;
+            if (!scanner.takeDigits(1, 7, parts.fractionTicks, &digits)) return false;
+            while (digits < 7) { parts.fractionTicks *= 10; ++digits; }
+        }
+    }
+    return true;
+}
+
+/**
+ * @brief Consumes a signed UTC offset, transcribing .NET's `ParseTimeZone`.
+ *
+ * @verbatim
+ *     ('+'|'-') ( d{1,2} [ ':' d{1,2} ] | d{3,4} )
+ * @endverbatim
+ *
+ * The three-or-four-digit run is split as `value / 100` hours and `value % 100`
+ * minutes, so `"+800"` and `"+0800"` both mean eight hours
+ * (`Globalization/DateTimeParse.cs:530-556`). The minute field is rejected at 60
+ * and above, which is .NET's only check here
+ * (`DateTimeParse.cs:565-568`); the +/-14h bound belongs to the caller, because
+ * .NET applies it later and only where an offset is actually stored
+ * (`DateTimeParse.cs:2777,2875`).
+ *
+ * Ticket #1929 row 3 (decided 2026-08-18). Before it, all three doors demanded
+ * exactly `+HH:MM`, so `"+2:5"`, `"+8"` and `"+0800"` were rejected -- and the
+ * first of those had been read as 2h05m, the value .NET gives it, until #1879
+ * narrowed the grammar.
+ *
+ * @param scanner       Cursor positioned at the sign character.
+ * @param signedMinutes Receives the offset in minutes, negative for `'-'`.
+ * @return @c true when a well-formed offset was consumed.
+ */
+[[nodiscard]] inline bool takeUtcOffsetMinutes(DateTimeTextScanner& scanner,
+                                               int& signedMinutes) noexcept {
+    bool negative = false;
+    if (scanner.take('-')) {
+        negative = true;
+    } else if (!scanner.take('+')) {
+        return false;
+    }
+
+    int value = 0, digits = 0;
+    if (!scanner.takeDigits(1, 4, value, &digits)) return false;
+
+    int hours = 0, minutes = 0;
+    if (digits <= 2) {
+        hours = value;
+        if (scanner.take(':')) {
+            if (!scanner.takeDigits(1, 2, minutes)) return false;
+        }
+    } else {
+        hours   = value / 100;
+        minutes = value % 100;
+    }
+    if (minutes >= 60) return false;
+
+    signedMinutes = hours * 60 + minutes;
+    if (negative) signedMinutes = -signedMinutes;
+    return true;
+}
+
 } // namespace System::detail

modules/core/include/System/detail/DateTimeTextScanner.hpp

@@ -178,12 +178,17 @@ bool DateOnly::TryParse(const std::string& s, DateOnly& result) {
     // "2024-06-15 10:20:30" -- a full timestamp silently truncated to its date.
     // The grammar is now required to match the WHOLE string:
     //
-    //     yyyy '-' MM '-' dd [ 'Z'|'z' ]
+    //     yyyy '-' M{1,2} '-' d{1,2} [ 'Z'|'z' ]
+    //
+    // #1929 row 1 (decided 2026-08-18): the month and day admit one or two digits,
+    // as .NET's do. The year stays exactly four -- three or fewer would collide with
+    // .NET's two-digit-year century window, which is culture state this port has no
+    // way to carry.
     detail::DateTimeTextScanner scanner(detail::trimDateTimeText(s));
     int y = 0, m = 0, d = 0;
     if (!scanner.takeDigits(4, 4, y) || !scanner.take('-') ||
-        !scanner.takeDigits(2, 2, m) || !scanner.take('-') ||
-        !scanner.takeDigits(2, 2, d))
+        !scanner.takeDigits(1, 2, m) || !scanner.take('-') ||
+        !scanner.takeDigits(1, 2, d))
         return fail();
     // A trailing UTC designator stays accepted and stays ignored, matching
     // DateTime::TryParse; "2024-06-15Z" parsed before this ticket and still does.

modules/core/src/System/DateOnly.cpp

@@ -410,58 +410,50 @@ namespace System {
         // (docs/DateTimeValidationBoundaryPlan.md §16.4 keeps widening it out of
         // scope), now required to match the WHOLE string:
         //
-        //     W* yyyy '-' MM '-' dd
+        //     W* yyyy '-' M{1,2} '-' d{1,2}
         //        [ (' '|'T') H{1,2} ':' m{1,2} ':' s{1,2} [ '.' f{1,7} ] ]
-        //        [ 'Z'|'z' ] W*
+        //        [ 'Z'|'z' | ('+'|'-') offset ] W*
         //
         // Every currently-valid input still produces its exact previous value.
         // Correction/remediation (#1929 rows 5-6, approved 2026-08-01): the preceding
         // historical grammar accurately described the repaired #1879 subset, but it was
         // narrower than both the related port doors and current .NET. Outer invariant
         // whitespace, one-or-two digit clock fields, and one through seven fractional
-        // digits are now the approved shared contract. Date fields, offsets and internal
-        // whitespace remain deliberately fixed/rejected.
+        // digits became the approved shared contract then; internal whitespace is still
+        // grammar, and still rejected.
+        //
+        // #1929 rows 1 and 3 (decided 2026-08-18) finish the job: the MONTH and DAY
+        // admit one or two digits, and the offset is .NET's ParseTimeZone grammar. Both
+        // are pure widenings -- no string that parsed yesterday parses differently or
+        // fails today -- and both now live in System/detail/DateTimeTextScanner.hpp so
+        // that the three doors sharing them cannot drift apart again.
         detail::DateTimeTextScanner scanner(detail::trimDateTimeText(s));
-        int yr = 0, mo = 0, dy = 0, hr = 0, mn = 0, sc = 0, fractionTicks = 0;
-        if (!scanner.takeDigits(4, 4, yr) || !scanner.take('-') ||
-            !scanner.takeDigits(2, 2, mo) || !scanner.take('-') ||
-            !scanner.takeDigits(2, 2, dy))
-            return fail();
-
-        if (scanner.take(' ') || scanner.take('T')) {
-            if (!scanner.takeDigits(1, 2, hr) || !scanner.take(':') ||
-                !scanner.takeDigits(1, 2, mn) || !scanner.take(':') ||
-                !scanner.takeDigits(1, 2, sc))
-                return fail();
-            if (scanner.take('.')) {
-                // A fraction must have 1-7 digits. A bare ".", a non-numeric
-                // ".abc", and an eighth digit are rejected rather than read as a
-                // prefix. DateTime is tick-based, so every accepted digit is retained.
-                int digits = 0;
-                if (!scanner.takeDigits(1, 7, fractionTicks, &digits)) return fail();
-                while (digits < 7) { fractionTicks *= 10; ++digits; }
-            }
-        }
+        detail::DateTimeParts        parts;
+        if (!detail::takeDateTimeParts(scanner, parts)) return fail();
+
         // A trailing time-zone designator stays accepted, and stays ignored: this
         // port has no DateTimeKind (§16.4), so "…T10:20:30Z" and
         // "…T10:20:30.123+02:00" keep the exact values they have always had.
         // §20.1's "unchanged in every option" list names both spellings, and
-        // three DateTimeTests pin the offset one. The offset fields are two
-        // digits each, the same rule DateTimeOffset applies -- and the same rule
-        // the date fields have always had, since "2024-6-15" was never accepted
-        // either.
+        // three DateTimeTests pin the offset one.
+        //
+        // #1929 row 3 (decided 2026-08-18) widens WHICH offsets are accepted, not
+        // what any of them mean here: "+8", "+2:5", "+800" and "+0800" join
+        // "+02:05". The grammar lives in one place now, shared with
+        // DateTimeOffset, which is the door that actually uses the value.
         if (!scanner.take('Z') && !scanner.take('z')) {
-            if (scanner.take('+') || scanner.take('-')) {
-                int offsetHours = 0, offsetMinutes = 0;
-                if (!scanner.takeDigits(2, 2, offsetHours) || !scanner.take(':') ||
-                    !scanner.takeDigits(2, 2, offsetMinutes))
+            if (!scanner.atEnd()) {
+                int ignoredOffsetMinutes = 0;
+                if (!detail::takeUtcOffsetMinutes(scanner, ignoredOffsetMinutes))
                     return fail();
             }
         }
         if (!scanner.atEnd()) return fail();
 
         try {
-            result = DateTime(dateToTicks(yr, mo, dy, hr, mn, sc) + fractionTicks);
+            result = DateTime(dateToTicks(parts.year, parts.month, parts.day,
+                                          parts.hour, parts.minute, parts.second) +
+                              parts.fractionTicks);
             return true;
         } catch (...) { return fail(); }
     }