Fix for DatePicker doesnot updates the Format on Windows

[SuthiYuvaraj]

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 if this change resolves your issue. Thank you!

Issue Description

The standard .NET DateTime format strings (like "D", "f", "F", "g", "G", "m", "M", "o", "O", "r", "R", "s", "u", "U", "y", "Y") had no visible effect when applied to DatePicker controls on the Windows platform, while working correctly on other platforms like Android and iOS.

RootCause

The ToDateFormat method in CalendarDatePickerExtensions.cs was designed to handle custom format patterns (like "dd/MM/yyyy") but didn't properly handle standard .NET DateTime format strings. These single-character standard formats were being processed as if they were custom patterns with separators, causing them to return empty strings and have no formatting effect.

Description of Change

• Modified ToDateFormat to detect single-character standard format strings
• Added ConvertStandardFormat method that maps standard formats to appropriate CalendarDatePicker patterns

Issues Fixed

Fixes #30154
Fixes #30011

Note:

In WinUI's CalendarDatePicker, if a format is explicitly defined, that format remains fixed and is not influenced by Language(Culture) changes. Therefore, culture changes were not considered in this case.

Output Screenshot

Before Issue Fix	After Issue Fix

[dotnet-policy-service]

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

[jsuarezruiz]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[Copilot]

Pull Request Overview

This PR ensures that single-character standard .NET DateTime format strings (e.g., "D", "f", "g") now correctly influence the Windows DatePicker by mapping them to WinUI CalendarDatePicker patterns. It also adds unit tests to validate these mappings.

• Detect and handle standard .NET formats in ToDateFormat by introducing ConvertStandardFormat.
• Added Windows-specific handler tests for standard and default format strings.

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/Core/src/Platform/Windows/CalendarDatePickerExtensions.cs	Added single-character format detection in ToDateFormat and implemented ConvertStandardFormat mappings
src/Core/tests/DeviceTests/Handlers/DatePicker/DatePickerHandlerTests.Windows.cs	Added [Theory] tests for standard formats initializing correctly and defaults

Comments suppressed due to low confidence (1)

src/Core/tests/DeviceTests/Handlers/DatePicker/DatePickerHandlerTests.Windows.cs:62

• Tests cover most standard formats but omit 'u' and the round-trip 'o'/'O' patterns that are implemented in ConvertStandardFormat. Consider adding InlineData entries for "u", "o", and "O" to fully validate the new mappings.

		[Theory(DisplayName = "Standard Format Strings Initialize Correctly")]

[jsuarezruiz]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[jsuarezruiz]

The test is failing in this case: Standard Format Strings Initialize Correctly(format: "F", nativeFormat: "{dayofweek.full} {month.full} {day.integer}, {year"···)

Assert.Equal() Failure: Values differ\r\nExpected: {dayofweek.full} {month.full} {day.integer}, {year.full} {hour.integer}:{minute.integer(2)} {period.abbreviated}\r\nActual: {dayofweek.full} {month.full} {day.integer}, {year.full} {hour.integer}:{minute.integer(2)}:{second.integer(2)} {period.abbreviated}

[SuthiYuvaraj]

@jsuarezruiz ,I have addressed the testcase failure. Let me know if anything else needs adjustment.

[jsuarezruiz]

/azp run MAUI-UITests-public

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).