The Duration difference between TimePicker.instant and Clock.Now on Android is from a date in 1970 but on iOS it is from today's date.
I have switched this category to iOS because the time picker instant on Android has always returned the epoch date 1/1/1970, and even though the iOS output you are reporting makes more sense it is out of line with what happens on Android. 
1 Like
Thanks for adding this information and updating it to the relevant topic.
@TIMAI2 I agree with your "makes more sense" comment, but understand that backwards compatibility is valuable. However... this opens up a different line of questioning... Could/Should TimePicker.SetTimeToDisplayFromInstant on Android adjust the TimePicker Instant's date?
It doesn't, because I believe it just extracts the hours and minutes as strings/numbers and sets the values of the display picker.
Could/Should ???
Probably better that it matched what iOS is doing.
1 Like
@Anke Thanks for including those. (I bumped into some of those crashes while trying to identify the bug I documented.)
Could/Should ???
@TIMAI2 What I meant is: TimePicker.Instant has a date of 1-1-1970. Would it be possible to maintain that, but if TimePicker.SetTimeToDisplayFromInstant is called, could TimePicker.Instant now return a date assigned by the prior call?
It could, but that would mean rewriting the original android timepicker code in order to make that happen. A pull request (PR) would need to be submitted. This is unlikely to be a high priority for the MIT team, and would take some time to work its way through to release.
You can work around it by using Clock1.Now and some string manipulation.
1 Like
