TimePicker includes seconds when UseSeconds is false in 11.2.0-beta1&2

[VisualMelon]

Describe the bug

When TimePicker.UseSeconds is false, the seconds component is still included in the resulting TimeSpan value. Further, the value defaults to the current time, so the seconds component can (and usually will) be non-zero by default. This makes this a behaviour breaking change.

To Reproduce

Easy to demo in the sandbox with this XAML alone: selecting a time with the TimePicker will update the TextBlock, and unless you are unlucky it will probably have a seconds component, revealing the breaking change.

  <StackPanel>
    <TimePicker x:Name="Picker" />
    <TextBlock Text="{Binding #Picker.SelectedTime}" />
  </StackPanel>

Sandbox example with simple fix in VisualMelon@6b6d24b

Expected behavior

In the specific example above, there should be no seconds component in the resulting TimeSpan (to address the breaking change). It's not entirely clear what the behaviour should be when e.g. changing the state of UseSeconds, as that's all new behaviour in the Beta, and I'm not familiar with how this is handled in other UI libraries. Additional discussion in #16079 (comment)

Avalonia version

11.2.0-beta2

OS

No response

Additional context

Only applies to the 11.2.0 betas which introduce TimePicker.UseSeconds

[VisualMelon]

Pinging @begleysm from the original discussion who described candidate fixes for the more interesting issues this creates when UseSeconds changes value.

I'm happy to work on this if we can nail down the expected behaviour: the trivial fix of simply not including the seconds component when UseSeconds is false is sufficient for my purposes, but in particular the case of having UseSeconds changing from true to false is problematic, as it won't currently update the TimeSpan, which feels wrong to me, and then it's unclear what should happen if it changes back to true again.

My reckoning now (though I've changed my mind 3 times already) is that it should be cleared when UseSeconds is false, and the internal values should only be non-zero when UseSeconds is true (so changing it from true to false and back to true should set it to zero), though I'm not sure how painful it would be to keep the seconds component from the current time when UseSeconds is bound to true from the outset.

[begleysm]

Thanks @VisualMelon. I'm recreating my suggested fix (from the other discussion) here for convenience.

Something tangentially related that I noticed is that, interestingly (in the absence of it being set manually with UseSeconds == true), newTime.Seconds appears to be set to be equal to the current time when the Control is first clicked on (not when it is first loaded or when the check button is clicked to set the time) and then stays that way forever (doesn't update even when the Control is clicked again or another control is clicked and then this control is clicked again). I'm not, currently, entirely sure why this is and it also isn't super relevant to this particular issue.

As for addressing this particular issue... Changing the modified line to

newTime = (UseSeconds) ? 
                        new TimeSpan(hr, newTime.Minutes, newTime.Seconds) :
                        new TimeSpan(hr, newTime.Minutes, 0);

causes 0 to be used for seconds when UseSeconds == false & the selected seconds to be used for seconds when UseSeconds == true. But it doesn't, alone, address the case where UseSeconds switches from false to true.

Regarding when UseSeconds == false changes to UseSeconds == true. That is also a good edge case you've identified. We can detect this case in the UseSeconds portion of the OnPropertyChanged override method.
We can detect that UseSecond went from false to true and pass an argument to SetSelectedTimeText() to indicate that 0 should be used for seconds.

It could look something like this which should result in

• using a 0 for seconds if UseSeconds == false
• using a 0 for seconds if UseSeconds == true but we came this method because UseSeconds went from false to true
• otherwise (if UseSeconds == true but was not just changed from false) using the SelectedTime.Seconds for seconds
  

[VisualMelon]

Could do with some direction from the maintainers on how to proceed with this: it's a serious breaking change, and I'm happy to work on it, though I can't comment on what the behaviour should be in non-trivial circumstances discussed above.

I'll open a PR with VisualMelon@6b6d24b if there are no concrete suggestions otherwise, as that at least avoids the breaking change. My vote for a complete solution would still be to zero the seconds value any time UseSeconds is set to false (hasn't changed recently)