DateTimePicker: Open at Today if null or default

[w3ori]

Fix

• MudDateTimePicker DateOnly opens at year 1 #637

[codecov]

Codecov Report

❌ Patch coverage is 50.00000% with 17 lines in your changes missing coverage. Please review.
✅ Project coverage is 65.59%. Comparing base (7b5faf7) to head (43c15c2).

Files with missing lines	Patch %	Lines
...mponents/DateTimePicker/MudDateTimePicker.razor.cs	34.78%	11 Missing and 4 partials ⚠️
...ns/Components/DateTimePicker/MudBaseDatePickerX.cs	81.81%	0 Missing and 2 partials ⚠️

❌ Your patch check has failed because the patch coverage (50.00%) is below the target coverage (90.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files

@@            Coverage Diff             @@
##              dev     #644      +/-   ##
==========================================
+ Coverage   65.42%   65.59%   +0.16%     
==========================================
  Files         111      111              
  Lines        8384     8399      +15     
  Branches     1480     1486       +6     
==========================================
+ Hits         5485     5509      +24     
+ Misses       2391     2378      -13     
- Partials      508      512       +4     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[w3ori]

@mckaragoz Can you look at this please?

[mckaragoz]

This PR is not the ultimate solution. With this solution, we only hide the real value and show something else. And with this PR, the min value of types will be unusuable.

I offer to add a new parameter like:

[Parameter]
public T? ValueOnClear { get; set; } = default;

And change the clear process:

public override async Task ClearAsync(bool close = true)
{
    await SetDateAsync(ToDateTime(ValueOnClear), true);

    if (AutoClose || close)
        await CloseAsync(false);
}

With this offered solution, you can easily set the date when user click on clear button. If no value set with parameter, it still goes to null for nullable types and min value for non nullable types. I think it's the best option, because you shouldn't set null value on non nullable types.

Could you change your PR with this solution?

[mckaragoz]

Looks good. Did you manually check the behavior also?

[w3ori]

It still needs some improvements, because for non nullable types it starts from year 1 when you clear it.

DateOnly

DateOnly?

[w3ori]

@mckaragoz Can you check the changes please?
Default was a good idea, but wasn't working for not nullable date types, because the default for those is 0001/01/01.

[mckaragoz]

I understand what you want to achieve. But it brings more problem. Non-nullable types can't be null. You hide the text on the component but the value still persists. So if user saves the cleared time, it sends 01/01/0001 to database, not null. It may cause data inconsistency.

Normally we should use nullable types for better results. For non-nullable types we should find another solution like optional parameter etc. The value and text should always be the same. The component should only have one truth.

[mckaragoz]

Default was a good idea, but wasn't working for not nullable date types, because the default for those is 0001/01/01.

The idea is "dynamic" default that can change with a parameter. So the component goes to a certain date when it reset or clear. With this way both developer and user can easily understand what is the true date for the component.

[w3ori]

ValueOnClear defines the replacement value assigned when the clear icon is clicked.

Nullable values clear to null by default.

<MudDateTimePicker @bind-Value="_dateTime"
                   ValueOnClear="@DateTime.Now" />

<MudDateTimePicker @bind-Value="_dateTimeOffset"
                   ValueOnClear="@DateTimeOffset.Now" />

<MudDateTimePicker @bind-Value="_dateOnly"
                   ValueOnClear="@DateOnly.FromDateTime(DateTime.Now)" />

[w3ori]

@mckaragoz I came up with another solution from a different perspective.
Please take a look at it. It only affects where the picker opens.

[mckaragoz]

It's nice. The only thing is the header date value. When we clear date, it correctly shows the min date on input, but when we open popover header shows today's date. I think header value should also be the same as input's. We should only change the picker time, not the header value.

[w3ori]

Prefer MinDate in the header and use BoundDateOrNull to treat default non‑nullable sentinels as absent, keeping the header consistent with the input and preventing the year selector from jumping to year 0001.

[w3ori]

Improve test coverage

[mckaragoz]

I think it's ok. Could you fix the test that failed on CI?

[w3ori]

DateTimePicker header fallback change

Problem

When Value is null and no MinDate is provided, the picker header fell back to the component's internally-initialized PickerMonth (first day of the month) instead of DateTime.Today. This made the header show e.g. 2026-10-01 instead of 2026-10-05 (today), which is surprising when the consumer never set PickerMonth.

Change

• Added an internal flag _picker_month_set to MudBaseDatePickerX.
• The PickerMonth property setter sets _picker_month_set = true when assigned.
• GetPickerHeaderDate(...) now uses PickerMonth only when _picker_month_set is true; otherwise it falls back to the current local date (TimeProvider.GetLocalNow().Date).

Why

This preserves the public PickerMonth API for consumers who explicitly set or bind it, while preventing internal initialization (component setting the month for view purposes) from affecting the header's intended fallback to today.

Files changed

• src/CodeBeam.MudBlazor.Extensions/Components/DateTimePicker/MudBaseDatePickerX.cs
  • Added _picker_month_set flag and updated PickerMonth setter.
• src/CodeBeam.MudBlazor.Extensions/Components/DateTimePicker/MudDateTimePicker.razor.cs
  • Updated GetPickerHeaderDate to consult _picker_month_set.

Testing

• Project builds successfully.
• Unit tests asserting header fallback to DateTime.Today should now pass for the case where PickerMonth was not explicitly set.
• Consider adding a unit test to verify that consumer-set PickerMonth still controls the header when provided.

Notes / Alternatives

• Alternative approaches considered: keep a private internal display-month field (never write public PickerMonth internally), or detect parameter origin via SetParametersAsync. The chosen approach is minimal and preserves external API/behavior for explicit consumer usage.