[Enhancement] TimePicker Inconsistencies

[memu8]

TimePicker Inconsistencies

Rationale:

Android

On Android, it operates normally when the format string is "HH:mm". Both the picker and display on the TimePicker change to a 24-hour or 12-hour clock. The Format property also overrides the device settings if set. However, if the time format string has "HH" but isn't "HH:mm," then the display and picker have different formats. More specifically, the display is 24-hour while the picker is 12-hour.

iOS

On iOS, the Format property only changes the display of the TimePicker while the picker widget always maintains the device’s default culture. Thus, if the Format property is specified to be different than the operating system time format, the display and picker aren’t consistent.

iOS also has two separate settings for region and language. However, if the region and language settings are set separately, then the TimePicker display and picker have different formats. For example, if the language is English and the region is France, then the picker is 24-hour while the display is 12-hour.

UWP

Finally, on UWP, the TimePicker’s current Format property does not have any effect on the TimePicker on UWP.

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:

Android Format

Phone region: US, Format = "HH:m"

iOS Format

Phone region: US, Format = "HH:mm"

iOS Region vs. Language

UWP

Format = "HH:mm"

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

Implementation:

We will parse the Format property, determine the clock type (12-hour or 24-hour), and then update the both the display and picker on the TimePicker (TimePicker Widget on Android, UITimePicker for iOS, and TimePicker ClockIdentifier on UWP) to use that clock.

Expected Result:

If the region and language are set differently, then the TimePicker’s default format should follow the region’s cultural format. Both the display and the picker should stay consistent with the region’s default.

If the Format property is set and the hour string in the TimePicker Format property is “HH,” then regardless of the device’s culture settings, both the TimePicker display and picker will both be in 24-hour. Similarly, if the hour string is “hh,” then both the TimePicker display and picker will both be in 12-hour.

If the Format property starts with “HH” (ex. “HH:mm” or “HH:mm tt”), then the expected result is a 24-hour clock display and picker regardless of device culture.

If the Format property starts with “hh” (ex. “hh:mm” or “hh tt”), then the expected result is a 12-hour clock display and picker regardless of device culture.

Example Usage:

If the region and language are set differently, then the TimePicker’s default format should follow the region’s cultural format. Both the display and the picker should stay consistent with the region’s default. However, if the Format property is set, then it should override the region’s default.

Backward Compatibility:

Android and iOS Format:

We are changing the effects of the Format property on the picker. 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 be in 24-hour while the picker to be in 12-hour. Otherwise, there should be no significant changes that need to be made.

iOS Region vs. Language:

We are changing the effects of the region and language on the TimePicker 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 language formatting while the picker to follows region formatting. 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 TimePickers, there should be no compatibility problems. The only issue is if developers wanted the format string on TimePickers to not affect UWP applications.