Validate the entire formats[] array up front in ParseExact/TryParseExact

[OlegRa]

Summary

Closes #118.

DateOnly/TimeOnly ParseExact and TryParseExact(string/span, string[]) validated each formats[] entry lazily, inside the parse loop. So a null/empty trailing entry was only detected if the loop actually reached it — if an earlier entry matched the input first, the method returned successfully and the bad entry was never inspected. Upstream dotnet/runtime's DateOnly/TimeOnly validate the whole array up front and throw FormatException immediately for any null/empty entry, regardless of position.

• Added a ThrowOnBadFormatSpecifier(string?[]? formats) helper (mirrors upstream's added validation pass) to both types, called from:
  • ParseExact(ReadOnlySpan<char>, string[], IFormatProvider?, DateTimeStyles)
  • TryParseExact(ReadOnlySpan<char>, string?[]?, IFormatProvider?, DateTimeStyles, out T)
• formats == null is left to the existing TryParseExactInternal check (unchanged) so the current null-formats behavior — ArgumentException from ParseExact, false from TryParseExact — is preserved exactly.
• The string-based overloads delegate into these span-based ones, so they inherit the fix automatically.
• Scope intentionally limited to ParseExact/TryParseExact(formats[]) should validate the whole array up front #118. TryParse/TryParseExact should throw for invalid DateTimeStyles, not return false #117 (invalid DateTimeStyles in Try*) is a separate, already-open PR (Throw ArgumentException for invalid DateTimeStyles in TryParse/TryParseExact #122) and isn't touched here; this branch is cut from master, not from that branch, so the two can merge independently.

Tests

• Updated two existing ArgumentValidationTests assertions ([], [string.Empty] with AllowWhiteSpaces) that expected false — they now expect FormatException, since a non-null single-entry-bad array is exactly what up-front validation catches.
• Added the regression case that actually demonstrates the gap: formats = ["yyyy-MM-dd", ""] / ["HH:mm:ss", ""] against an input the first format would have matched — before this fix these silently returned a parsed value, ignoring the bad trailing entry; now they throw FormatException for both ParseExact and TryParseExact, on both DateOnly and TimeOnly.

Test plan

• dotnet build -c Debug — succeeds, 0 warnings/errors
• dotnet test — 169/169 passed

[Copilot]

Pull request overview

This PR aligns DateOnly/TimeOnly ParseExact and TryParseExact(..., string[] formats, ...) behavior with upstream .NET by validating the entire formats[] array up front, ensuring null/empty entries are detected even when an earlier format would otherwise succeed.

Changes:

• Added an up-front ThrowOnBadFormatSpecifier(string?[]? formats) validation pass in DateOnly and TimeOnly.
• Updated TryParseExact (formats-array overload) to call the new helper before attempting parsing.
• Updated/added regression tests to assert FormatException is thrown for null/empty entries anywhere in the array.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File	Description
DateTimeOnly/TimeOnly.cs	Adds up-front formats-array validation for ParseExact/TryParseExact (formats overload).
DateTimeOnly/DateOnly.cs	Adds up-front formats-array validation for ParseExact/TryParseExact (formats overload).
DateTimeOnly.Tests/ArgumentValidationTests.cs	Updates expectations and adds regression tests for trailing bad format entries.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[OlegRa]

Rebased onto master (now includes #122) and addressed Copilot's 4 review comments — they were all valid, describing the same root issue at 4 call sites.

The bug: ThrowOnBadFormatSpecifier(formats) ran unconditionally as the first statement in ParseExact/TryParseExact, before any DateTimeStyles validation. If a caller passed both an invalid style and a malformed formats array at the same time, the method threw FormatException (about the bad format) instead of ArgumentException (about the bad style) — the wrong exception type, since upstream validates style first, then formats == null, then per-entry format validity.

Fix:

• TryParseExact (both types): now that Throw ArgumentException for invalid DateTimeStyles in TryParse/TryParseExact #122 added an explicit, unconditional style-throw at the top of the method, resolving the rebase conflict by putting that check before ThrowOnBadFormatSpecifier fixes the ordering with no extra logic needed.
• ParseExact (both types): there's no separate style-throw block here (style validation lives only inside TryParseExactInternal), so ThrowOnBadFormatSpecifier is now gated on (style & ~DateTimeStyles.AllowWhiteSpaces) == 0 — skipped when style is already invalid, letting TryParseExactInternal retain sole ownership of "what happens on invalid style".

Added two regression tests (one per type) that combine an invalid style with a bad formats[] entry and assert ArgumentException (not FormatException) — mirroring the equivalent coverage that already existed for TryParseExact via #122's tests, which is what caught this while resolving the conflict.

Rebuilt and re-ran the full suite: 169/169 passed.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.