Skip to content
This repository has been archived by the owner on May 1, 2024. It is now read-only.

# TimePicker Inconsistencies #11471

Closed
hartez opened this issue Jul 17, 2020 · 1 comment · Fixed by #11474
Closed

# TimePicker Inconsistencies #11471

hartez opened this issue Jul 17, 2020 · 1 comment · Fixed by #11474
Labels
a/timepicker blocker Issue blocks next stable release. Prioritize fixing and reviewing this issue. in-progress This issue has an associated pull request that may resolve it! t/bug 🐛
Milestone

Comments

@hartez
Copy link
Contributor

hartez commented Jul 17, 2020

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.

Originally posted by @memu8 in #11331

memu8 added a commit that referenced this issue Jul 17, 2020
memu8 added a commit that referenced this issue Jul 17, 2020
memu8 added a commit that referenced this issue Jul 17, 2020
memu8 added a commit that referenced this issue Jul 20, 2020
memu8 added a commit that referenced this issue Jul 20, 2020
memu8 added a commit that referenced this issue Jul 20, 2020
memu8 added a commit that referenced this issue Jul 20, 2020
memu8 added a commit that referenced this issue Jul 20, 2020
memu8 added a commit that referenced this issue Jul 20, 2020
memu8 added a commit that referenced this issue Jul 20, 2020
memu8 added a commit that referenced this issue Jul 21, 2020
memu8 added a commit that referenced this issue Jul 22, 2020
memu8 added a commit that referenced this issue Jul 22, 2020
@hartez hartez added the in-progress This issue has an associated pull request that may resolve it! label Jul 24, 2020
memu8 added a commit that referenced this issue Jul 24, 2020
memu8 added a commit that referenced this issue Aug 5, 2020
memu8 added a commit that referenced this issue Aug 5, 2020
memu8 added a commit that referenced this issue Aug 5, 2020
memu8 added a commit that referenced this issue Aug 5, 2020
memu8 added a commit that referenced this issue Aug 5, 2020
memu8 added a commit that referenced this issue Aug 20, 2020
memu8 added a commit that referenced this issue Aug 20, 2020
memu8 added a commit that referenced this issue Aug 20, 2020
memu8 added a commit that referenced this issue Aug 20, 2020
memu8 added a commit that referenced this issue Aug 20, 2020
memu8 added a commit that referenced this issue Aug 20, 2020
memu8 added a commit that referenced this issue Aug 20, 2020
memu8 added a commit that referenced this issue Aug 20, 2020
@samhouts samhouts removed this from the 5.0.0 milestone Nov 2, 2020
@PureWeen PureWeen added this to the 5.0.0 milestone Nov 5, 2020
@PureWeen PureWeen added the blocker Issue blocks next stable release. Prioritize fixing and reviewing this issue. label Nov 5, 2020
PureWeen pushed a commit that referenced this issue Nov 10, 2020
PureWeen pushed a commit that referenced this issue Nov 10, 2020
PureWeen pushed a commit that referenced this issue Nov 10, 2020
PureWeen pushed a commit that referenced this issue Nov 10, 2020
PureWeen pushed a commit that referenced this issue Nov 10, 2020
PureWeen pushed a commit that referenced this issue Nov 10, 2020
PureWeen pushed a commit that referenced this issue Nov 10, 2020
PureWeen pushed a commit that referenced this issue Nov 10, 2020
PureWeen pushed a commit that referenced this issue Nov 10, 2020
PureWeen pushed a commit that referenced this issue Nov 10, 2020
PureWeen pushed a commit that referenced this issue Nov 10, 2020
PureWeen pushed a commit that referenced this issue Nov 10, 2020
PureWeen pushed a commit that referenced this issue Nov 10, 2020
rmarinho pushed a commit that referenced this issue Nov 11, 2020
#12556

* fix date and time picker localizations

* fixed UWP datepicker

* edited UWP datepicker

* added UI tests for datetime picker localization

* Fixes #11472
Fixes #11471

* fixes #11471 fixes #11472

* fixes #11471 fixes #11472

* fixes #11471 #11472

* fixes #11471 #11472

* fixes #11471 #11472

* reverted csproj

* fixes #11471 #11472

* fixes #11471 #11472

* fixes #11471 #11472

* fixes #11471 #11472

* fixes #11471 #11472

* fixes #11471 #11472

* fixes #11471 #11472

* Update Xamarin.Forms.ControlGallery.Tizen.csproj

* Update ErrorMessages.Designer.cs

* - fix uwp

Co-authored-by: Shane Neuville <[email protected]>
@brigosx
Copy link

brigosx commented Jul 7, 2023

Hi to all,

I know that this issue is closed but I still face issues with iOS time picker. I have Xamarin Forms V5.0.0.2578 and applied custom renderers for both iOS and Android devices. For iOS devices (v 16.1 and greater) the time settings of the device overrides the format property (set to "HH:mm") and the custom renderer which has a code like the following one:

protected override void OnElementChanged(ElementChangedEventArgs<TimePicker> e)
{
	base.OnElementChanged(e);
        if (Control != null)
        {
            var timePicker = (UIDatePicker)Control.InputView;
            timePicker.Locale = new NSLocale("no_nb");
        }
}

The expected behavior would be to display the time view in 24 hours mode regardless of the device settings. It works fine in iOS simulator and Android devices.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
a/timepicker blocker Issue blocks next stable release. Prioritize fixing and reviewing this issue. in-progress This issue has an associated pull request that may resolve it! t/bug 🐛
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants