# DatePicker Inconsistencies

[memu8]

DatePicker Inconsistencies

Rationale:

Android

On Android, the DatePicker operates normally. Since the picker is a calendar graphic, the display on the DatePicker changes to follow the month, day, year ordering depending on the string in the Format property. The Format property also overrides the device default if set.

iOS

On iOS, there are two separate settings for region and language. However, if the region and language settings are set separately, then the DatePicker display and picker have different formats. For example, if the language is English and the region is France, then the picker shows day/month/year while the display shows month/day/year.

UWP:

Finally, UWP’s DatePicker feature currently is only able to support the ordering month, day, and then year. However, it still can support the numeric (ex. November as 11) and abbreviated (ex. November as Nov.) of months. It can also support an abbreviated year (ex. 2019 as 19). In Xamarin.Forms, the DatePicker’s current Format property does not have any effect on UWP. For example, when the format is set as “MM/dd/yyyy” the month still appears as November rather than 11.

This bugfix will allow developers to get consistent default behaviour of the display and picker, as well as specify a Format property that will change both the display and picker widget accurately on all platforms.

Current Issue Example:

iOS:

UWP:

Format = “MM/dd/yyyy”

NOTE: Here is a demo repo that illustrates what the format string changes on the DatePicker. Running this repo will show you what is happening in real time.

Implementation:

We will use the native platform’s date format given the region and language settings, and then update the display to stay consistent with that format. If the Format property is set, then we will parse the Format property, determine the type of month and year (numeric/abbreviated/default), and then update the DatePicker to use that format.

Expected Result:

iOS:

If the region and language are set differently, then the DatePicker’s default format should follow the Apple’s date/time display in settings. Both the display and the picker should stay consistent with the the iOS default while any strings (ex. month names) should respect the language setting.

If Region = US, Language = French, then the expected result is a day/month/year display with the month names in French.

If Region = France, Language = English, then the expected result is a day/month/year display with the month names in English.

UWP:

If the month string in the DatePicker Format property is “MM,” then regardless of the device’s culture settings, both the DatePicker display and picker will both have month in a numeric format. Similarly, if the month string is “MMM,” then both the DatePicker display and picker will have abbreviated months. Finally, if the year string is “yy,” then the DatePicker display and picker will both have abbreviated years.

Since the ordering of the DatePicker on UWP is inflexible, we will throw an exception if the format string has any other format besides month, day, year.

If the format string is in any other order than month/day/year, then the expected result is throwing an exception.

If the month is “MM,” then the expected result is having a numerical month like 11 instead of November.

If the month is “MMM,” then the expected result is having an abbreviated month like Nov.

If the year is “yy,” then the expected result is 19 instead of 2019.

Example Usage:

It would still be used in the same way that the Format property is currently being used.

Backward Compatibility:

iOS:

We are changing the effects of the region and language on the DatePicker display format. There could be a potential issue if a developer wants the format of the display and the picker to be different. For example, if they deliberately wanted the display to follow the language formatting while the picker followed region. Otherwise, there should be no significant changes that need to be made.

UWP:

Since we are adding a feature and making the Format property accurately affect UWP DatePickers, there should be no compatibility problems. The only issue is if developers wanted the format string on DatePickers to not affect UWP applications.

Originally posted by @memu8 in #11332