[Windows] Throws ArgumentOutOfRangeException on WinUI when setting MaximumDate to null

[SubhikshaSf4851]

Note

Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment whether this change resolves your issue. Thank you!

This pull request updates how the maximum date is set for the CalendarDatePicker on Windows to handle edge cases with time zone conversions. Instead of using DateTime.MaxValue when no maximum date is provided, it now sets the maximum date to 100 years from the current date to avoid overflow errors in negative UTC timezones.

Description of Change

Previously, UpdateMaximumDate used DateTime.MaxValue as the fallback value. In negative UTC offset time zones, the control internally converts the value to UTC, which can exceed the supported DateTime range and result in an overflow exception.

To avoid this, the fallback maximum date is now set to 100 years from the current date instead of DateTime.MaxValue. This provides a practical upper bound while preventing overflow during time zone conversion.

Why Tests not added :

This scenario requires the operating system time zone to be configured with a negative UTC offset.

Since changing the system time zone is an OS-level operation and cannot be reliably automated within our test environment, a regression test was not added.

Issues Fixed

Fixes #35785

Tested the behavior in the following platforms

• Windows
• Android
• iOS
• Mac

ScreenShots :

Before Fix	After Fix

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 35894

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 35894"

[dotnet-policy-service]

Hey there @@SubhikshaSf4851! Thank you so much for your PR! Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[kubaflo]

/review -b feature/enhanced-reviewer

[kubaflo]

/review -b feature/enhanced-reviewer -p windows

[MauiBot]

Expert Review — 2 findings

See inline comments for details.

[kubaflo]

/review rerun

[MauiBot]

Expert Review — 2 findings

See inline comments for details.

[MauiBot]

AI Review Summary

@SubhikshaSf4851 — new AI review results are available based on this last commit: 33e37c5. To request a fresh review after new comments or commits, comment /review rerun.

Review Sessions — click to expand

Gate — Test Before & After Fix

Gate Result: ⚠️ SKIPPED

No tests were detected in this PR.

Recommendation: Add tests to verify the fix using the write-tests-agent.

---

UI Tests — DatePicker,ViewBaseTests

Detected UI test categories: DatePicker,ViewBaseTests

✅ Deep UI tests — 138 passed, 0 failed across 2 categories on platform-pool agent (replaces in-process counts above).

🧪 UI Test Execution Results (deep, platform pool)

Category	Tests	Snapshot diffs
DatePicker	23/23 ✓	—
ViewBaseTests	115/115 ✓	—
📎 Download drop-deep-uitests artifact (TRX + snapshot diffs)

---

Pre-Flight — Context & Validation

Issue: #35785 - DatePicker: Throws ArgumentOutOfRangeException on WinUI when setting MaximumDate to null
PR: #35894 - [Windows] Throws ArgumentOutOfRangeException on WinUI when setting MaximumDate to null
Platforms Affected: Windows
Files Changed: 1 implementation, 0 test

Key Findings

• The issue reproduces on Windows in negative UTC-offset time zones when DatePicker.MaximumDate = null; MAUI maps null to DateTime.MaxValue, then WinUI's DateTime to DateTimeOffset conversion overflows.
• PR #35894 changes the null fallback to DateTime.Now.AddYears(100), avoiding the narrow null crash but introducing a finite moving cap where documentation/issue context expect an effectively unbounded maximum.
• No tests were added; the prior gate result was skipped because no tests were detected.
• Existing inline review comments already flagged that explicit MaximumDate = DateTime.MaxValue remains vulnerable and that DateTime.Now.AddYears(100) changes null semantics.
• GitHub CLI was unauthenticated in this environment; PR and issue metadata were fetched through the public GitHub REST API and patch URL instead.

Code Review Summary

Verdict: NEEDS_CHANGES
Confidence: low
Errors: 2 | Warnings: 1 | Suggestions: 0

Key code review findings:

• ❌ src/Core/src/Platform/Windows/DatePickerExtensions.cs:55 still assigns explicit MaximumDate values through implicit DateTime to DateTimeOffset conversion, so DateTime.MaxValue can still overflow in negative UTC-offset time zones.
• ❌ src/Core/src/Platform/Windows/DatePickerExtensions.cs:62 maps null to DateTime.Now.AddYears(100), changing expected effectively-unbounded behavior into a finite moving cap.
• ⚠️ No regression coverage was added for null maximum fallback or max-boundary conversion.

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #35894	Replace null MaximumDate fallback from DateTime.MaxValue to DateTime.Now.AddYears(100) in Windows DatePickerExtensions.UpdateMaximumDate.	⚠️ SKIPPED (Gate: no tests detected)	src/Core/src/Platform/Windows/DatePickerExtensions.cs	Original PR; avoids one crash path but has unresolved semantics/max-value concerns.

---

Code Review — Deep Analysis

Code Review — PR #35894

Independent Assessment

What this changes: Windows DatePickerExtensions.UpdateMaximumDate no longer uses DateTime.MaxValue when MaximumDate is null; it uses DateTime.Now.AddYears(100) instead.
Inferred motivation: Avoid DateTime → DateTimeOffset overflow in negative UTC-offset time zones.

Reconciliation with PR Narrative

Author claims: Fixes ArgumentOutOfRangeException when MaximumDate = null on WinUI.
Agreement/disagreement: Agree on root cause, but the fix is incomplete: explicit MaximumDate = DateTime.MaxValue still uses the unsafe implicit conversion, and null now becomes a finite ~100-year cap rather than unbounded.

Prior Review Reconciliation

Prior ❌ Error Finding	Source	Status	Evidence
Explicit MaximumDate = DateTime.MaxValue still overflows in negative UTC time zones	MauiBot [critical] inline comment	❌ Unresolved	Current line 55 still assigns datePicker.MaximumDate.Value to WinUI MaxDate, invoking implicit DateTimeOffset conversion.
MaximumDate = null becomes a moving ~2126 cap instead of effectively unbounded	MauiBot [major] inline comment	❌ Unresolved	Current line 62 sets DateTime.Now.AddYears(100). Author reply did not change code.

Blast Radius Assessment

• Runs for all instances: Yes — mapper applies whenever Windows DatePicker maximum date is initialized/updated.
• Startup impact: Possible for pages containing DatePicker with null/default MaximumDate.
• Static/shared state: No.

CI Status

• Required-check result: gh pr checks --required unavailable due unauthenticated gh.
• Fallback evidence: public check-runs show maui-pr and Build Analysis failed on Android integration tests.
• Classification: likely PR-unrelated, since failures are Android template/binlog-reading failures while PR changes Windows DatePicker only.
• Action taken: invoked azdo-build-investigator; confidence capped low due red CI/tool limitation.

Findings

❌ Error — Explicit maximum values can still hit the same overflow

src/Core/src/Platform/Windows/DatePickerExtensions.cs:55 still assigns a DateTime directly to CalendarDatePicker.MaxDate. If an app sets MaximumDate = DateTime.MaxValue, WinUI still receives the unsafe implicit DateTimeOffset conversion and can throw in negative UTC-offset time zones. Use a safe conversion or assign DateTimeOffset.MaxValue for max-boundary cases.

❌ Error — Null maximum changes documented/unbounded behavior into a finite cap

src/Core/src/Platform/Windows/DatePickerExtensions.cs:62 maps null to DateTime.Now.AddYears(100). That avoids the crash but makes clearing MaximumDate reject dates beyond ~100 years, whereas the previous intent was effectively unbounded. DateTimeOffset.MaxValue would avoid overflow without introducing this cap.

⚠️ Warning — No regression coverage

No test was added. Existing Windows DatePicker handler tests cover explicit nearby dates, but not null maximum fallback or max-boundary conversion. A Windows handler/device test should verify null/default MaximumDate does not crash and preserves expected max semantics.

Failure-Mode Probing

• MaximumDate = null on UTC-8 startup: no DateTime.MaxValue overflow, but UI is capped at ~100 years.
• MaximumDate = DateTime.MaxValue: still vulnerable to the same overflow path.
• Handler reconnect/property remap: no subscription/static-state issue, but the same mapper behavior repeats each time.

Verdict: NEEDS_CHANGES

Confidence: low
Summary: The PR fixes the narrow null crash path but leaves a closely related explicit max-value crash and changes null semantics. Prior critical/major findings remain unresolved, and CI is red though likely unrelated.

---

Fix — Analysis & Comparison

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
1	try-fix-1	Assign CalendarDatePicker.MaxDate as DateTimeOffset: explicit values use new DateTimeOffset(maximumDate, TimeSpan.Zero), null uses DateTimeOffset.MaxValue.	✅ Build passed; ⚠️ regression execution blocked	1 file	Best direct fix for both null and explicit DateTime.MaxValue; possible semantic change for ordinary explicit dates because it avoids local offset conversion.
2	try-fix-2	Use safe local clamping: null maps to DateTimeOffset.MaxValue.ToLocalTime(), explicit values above that local boundary are clamped, ordinary values keep existing assignment.	✅ Build passed; ⚠️ regression execution blocked	1 file	Preserves ordinary local-date behavior and handles near-boundary overflow, but is more complex and silently clamps.
3	try-fix-3	Clear WinUI MaxDateProperty for null; special-case explicit DateTime.MaxValue to DateTimeOffset.MaxValue; ordinary explicit values keep existing assignment.	✅ Build passed; ⚠️ regression execution blocked	1 file	Small and behavior-preserving for ordinary dates, but likely incomplete for near-boundary dates and depends on WinUI default semantics.
PR	PR #35894	Replace null fallback with DateTime.Now.AddYears(100).	⚠️ Gate skipped; no tests detected	1 file	Original PR avoids the null crash path but leaves explicit max-value overflow and changes unbounded semantics.

Candidate Details

try-fix-1

Use DateTimeOffset at the platform boundary. This is the cleanest expression of the WinUI API type and avoids the problematic implicit local conversion for both null and explicit maximums.

try-fix-2

Keep the existing local DateTime behavior for ordinary explicit dates but compute a latest safe local maximum from DateTimeOffset.MaxValue.ToLocalTime() for null and near-boundary values.

try-fix-3

Let WinUI restore its default MaxDate dependency-property value when MAUI has no maximum, while guarding exact explicit DateTime.MaxValue.

Test Results

Candidate	Command	Result
try-fix-1	dotnet build src\Core\src\Core.csproj -f net10.0-windows10.0.19041.0 -p:IncludeWindowsTargetFrameworks=true -p:EnableWindowsTargeting=true --no-restore	✅ Passed
try-fix-2	dotnet build src\Core\src\Core.csproj -f net10.0-windows10.0.19041.0 -p:IncludeWindowsTargetFrameworks=true -p:EnableWindowsTargeting=true --no-restore	✅ Passed
try-fix-3	dotnet build src\Core\src\Core.csproj -f net10.0-windows10.0.19041.0 -p:IncludeWindowsTargetFrameworks=true -p:EnableWindowsTargeting=true --no-restore	✅ Passed

Regression/device execution remained blocked by the pre-existing gate result: no tests were detected in PR #35894, and no automated negative-time-zone repro test exists in this PR. The first attempted TFM (net10.0-windows10.0.26100.0) failed because restored assets only contained the repo-configured Windows TFMs (19041/20348); subsequent candidate builds used net10.0-windows10.0.19041.0.

Expert Review / Learn Loop

Round	Input	Result
Pre-flight code review	PR #35894 code and prior review comments	NEEDS_CHANGES: explicit DateTime.MaxValue still overflows; null mapped to DateTime.Now.AddYears(100) changes unbounded semantics; no regression coverage.
Candidate exhaustion review	Candidates 1-3 plus test outcomes	NO NEW IDEAS: remaining variants would only combine candidate 3's ClearValue null path with candidate 2's clamp, not a materially new strategy.

Failure Analysis

• PR fix is weaker than all compiled candidates because it addresses only null overflow and introduces a finite 100-year cap.
• try-fix-1 best satisfies the expert-review findings with the smallest robust conceptual model, but it should be reviewed for ordinary-date offset semantics.
• try-fix-2 is likely the safest behavior-preserving alternative for ordinary dates and near-boundary values, at the cost of more code and silent clamping.
• try-fix-3 is not preferred because it likely misses near-boundary explicit dates.

Exhausted: Yes
Selected Fix: Candidate #1 as the best alternative to the PR fix, with Candidate #2 as the conservative fallback if preserving local DateTime assignment semantics is required. Full validation still requires a Windows regression test or manual negative-UTC repro because build-only validation cannot prove the timezone crash scenario.

---

Recommended PR Title & Description

Assessment: ✏️ Recommend updating — the current title is close, but the description describes the raw PR's 100-year fallback and is stale for the winning pr-plus-reviewer fix.

Recommended title

[Windows] DatePicker: Use safe MaxDate DateTimeOffset conversion

Recommended description

### Description of Change

Updates the Windows `CalendarDatePicker.MaxDate` mapping used by `DatePicker.MaximumDate` so MAUI does not rely on unsafe implicit `DateTime` to `DateTimeOffset` conversion at the upper date boundary.

### Root Cause

`CalendarDatePicker.MaxDate` is a `DateTimeOffset?`. When MAUI supplied `DateTime.MaxValue` for a null maximum date, WinUI/.NET converted that `DateTime` through the local time zone. In negative UTC-offset time zones, that conversion can exceed the supported `DateTimeOffset` range and throw `ArgumentOutOfRangeException`.

The same conversion risk also applies when an app explicitly sets `MaximumDate = DateTime.MaxValue`.

### Fix

- Use `DateTimeOffset.MaxValue` directly when `DatePicker.MaximumDate` is null, preserving the effectively unbounded maximum-date behavior.
- Convert explicit `MaximumDate` values to `DateTimeOffset` with a fixed zero offset before assigning `CalendarDatePicker.MaxDate`, avoiding local time-zone overflow at the maximum boundary.

### What NOT to Do

- Do not use `DateTime.Now.AddYears(100)` for the null fallback; it avoids the crash but changes null maximum semantics into a moving finite cap.
- Do not assign explicit `DateTime.MaxValue` directly to `CalendarDatePicker.MaxDate`; that still uses the overflow-prone implicit conversion in negative UTC-offset time zones.

### Why Tests Were Not Added

The original reported crash depends on the operating system time zone being configured with a negative UTC offset. The PR currently has no automated regression test for that environment-dependent path.

### Issues Fixed

Fixes #35785

### Tested the behavior in the following platforms

- [x] Windows
- [ ] Android
- [ ] iOS
- [ ] Mac

---

Report — Final Recommendation

Comparative Report - PR #35894

Candidate ranking

Rank	Candidate	Regression/build result	Assessment
1	pr-plus-reviewer	✅ Build passed via equivalent STEP 5a candidate; ⚠️ regression execution blocked/no tests detected	Best candidate. Applies expert feedback to the PR by assigning DateTimeOffset.MaxValue for null maximums and using explicit zero-offset DateTimeOffset construction for explicit maximums. Fixes both the reported null overflow and the latent explicit max-value overflow while preserving effectively unbounded semantics.
2	try-fix-1	✅ Build passed; ⚠️ regression execution blocked	Technically equivalent to pr-plus-reviewer and sound for the same reasons, but ranked second because the requested PR-plus-reviewer path incorporates the expert review feedback into the PR candidate.
3	try-fix-2	✅ Build passed; ⚠️ regression execution blocked	Preserves ordinary local DateTime assignment and clamps null/near-boundary values to the latest safe local maximum. More behavior-preserving for non-boundary dates than zero-offset conversion, but more complex and silently clamps explicit inputs.
4	try-fix-3	✅ Build passed; ⚠️ regression execution blocked	Small and preserves ordinary explicit-date behavior, but depends on WinUI ClearValue(MaxDateProperty) default semantics and only protects exact DateTime.MaxValue, likely missing near-boundary explicit dates.
5	pr	⚠️ Gate skipped/no tests detected	Fixes only the null crash path. It leaves explicit MaximumDate = DateTime.MaxValue vulnerable and changes null maximum semantics into a moving 100-year cap.

Candidate details

pr

The raw PR replaces the null fallback with DateTime.Now.AddYears(100). This avoids assigning DateTime.MaxValue when MaximumDate is null, but the explicit branch still relies on implicit local DateTime to DateTimeOffset conversion. It also makes MaximumDate = null a finite moving cap instead of an effectively unbounded maximum.

pr-plus-reviewer

The expert-reviewed PR candidate uses:

platformDatePicker.MaxDate = datePicker?.MaximumDate is DateTime maximumDate
	? new DateTimeOffset(maximumDate, TimeSpan.Zero)
	: DateTimeOffset.MaxValue;

This is the strongest candidate because it directly addresses both expert findings with a small localized change and matches the WinUI property's DateTimeOffset boundary type.

try-fix-1

try-fix-1 is equivalent to the winning pr-plus-reviewer implementation. It passed the Windows Core build and fixes both null and explicit maximum overflow paths. Its only noted risk is a possible semantic difference for ordinary explicit dates because it avoids WinUI's local-time interpretation by using a zero offset.

try-fix-2

try-fix-2 computes DateTimeOffset.MaxValue.ToLocalTime() and clamps values above that local boundary. This preserves existing local DateTime assignment for ordinary dates and handles near-boundary overflow, but silent clamping is less transparent than assigning the platform API's maximum representable DateTimeOffset.

try-fix-3

try-fix-3 clears CalendarDatePicker.MaxDateProperty for null and maps exact DateTime.MaxValue to DateTimeOffset.MaxValue. It is smaller, but less complete: it depends on WinUI defaults for null semantics and can still miss near-boundary explicit values.

Winner

Winner: pr-plus-reviewer

pr-plus-reviewer wins because it is the PR fix plus the expert reviewer's actionable corrections, it ranks above the raw PR due to the unresolved correctness issues, and it is at least tied with the strongest try-fix candidate while remaining a PR-fix candidate. No candidate had regression-test execution; among build-passing candidates, the winner best preserves intended null/unbounded behavior and closes the explicit maximum overflow gap.

---

Future Action — review latest findings

No alternative fix was selected for this run. Review the session findings and CI results before merging.