Backport 41868 to release/6.0

[SteveSandersonMS]

Fix time/datetime-local binding with seconds when there's no step attribute

Restores the ability to do <input type=time @bind="someDateTimeVariable"> without getting a weird browser warning if someDateTimeVariable has a non-zero "seconds" component. This used to work in 5.0 but regressed in 6.0.

Description

In 5.0, there was explicit JS-side logic to handle the case where an <input type=time> had no step attribute (which browsers interpret as "use whole number of minutes - no seconds"). We automatically stripped off any "seconds" part of the formatted string to make it valid as far as the <input type=time> is concerned. This behavior was unintentionally lost in 6.0.

Fixes #41731

Customer Impact

Without this change:

• People upgrading 5.0 applications to 6.0
• Or, people writing new 6.0 applications without realising they would need to ensure bound DateTime or TimeOnly values have a zero "seconds" component when used with <input type=time> or <input type=datetime-local>

... would find that:

1. The UI displays a weird tooltip saying that the time value is invalid
2. The values retrieved from an <input type=time> or <input type=datetime-local> would have a nonzero "seconds" component only if they have not been edited by the user, which is pretty odd

Regression?

• Yes
• No

Worked in 5.0

Risk

• High
• Medium
• Low

It is plausible that a 6.0 developer has taken a dependency on this weird behavior. For example, they might be using the <input type=time> as a readonly value, and be relying on the ability to round-trip a value that includes a nonzero "seconds" part. However:

1. This is a bad UX, as the browser will be showing a tooltip saying the value is invalid
2. This would be a very flaky pattern to follow, because "input" elements are primarily intended for editing, and the moment the user edits the value, the "seconds" part would be reset to zero

The 5.0 behavior is objectively better, so I have no doubt we should fix this in 7.0. Whether or not we should also patch 6.0 and accept the risk that some developer actually wants the bug is a more ambiguous question.

Verification

• Manual (required)
• Automated

Packaging changes reviewed?

• Yes
• No
• N/A

[ghost]

Hi @SteveSandersonMS. If this is not a tell-mode PR, please make sure to follow the instructions laid out in the servicing process document.
Otherwise, please add tell-mode label.

[ghost]

Hi @SteveSandersonMS. Please make sure you've updated the PR description to use the Shiproom Template. Also, make sure this PR is not marked as a draft and is ready-to-merge.

To learn more about how to prepare a servicing PR click here.

[SteveSandersonMS]

cc @mkArtakMSFT

[SteveSandersonMS]

@mkArtakMSFT This can be merged

[mkArtakMSFT]

@wtgodbe when will the branches be ready to merge this? Can I merge this now?

[wtgodbe]

Branches will open after we do branding next Tuesday (6/7)