DateTimePicker: set PM hours correctly
#36878
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ciampo
added
[Feature] Component System
|
Size Change: +44 B (0%) Total Size: 1.1 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
Thanks for picking up this issue @ciampo! Unfortunately this introduces a regression, but it looks like it shouldn't be too hard to fix if we move some of the logic in update to a separate updateHours function. I've added some notes.
It might be nice to add an extra unit test to cover the AM/PM issue, too. We've already got a should switch to AM correctly test, but it looks like it only covers clicking the AM button, rather than the issue in #29720.
Thanks again, and happy to do more testing next week!
|
I can't reproduce the problem 😄 . Can you share a bit more testing instructions? |
Sure! Basically, when the component is using the 12 hour format and the period is set to datetimepicker-bug.mp4#29720 should also include some reproducible tests case |
|
Thanks! I was changing the hour and selecting |
Yes, I believe that's because the inputs in this component "commit" their new values on blur |
ntsekouras
reviewed
Nov 26, 2021
ciampo
force-pushed
the
feat/datetime-picker-fix-am-pm
branch
from
ea80f88 to
3532e49
Compare
Thank you for finding the time to review this and discover the regression (which was confirmed by some failing e2e/unit tests too 😅 ). That should be addressed now (more details under your inline comment).
Definitely — I've added a new unit test to the suite. I also think that this fix highlighted a bug in another unit test, which I corrected in this PR too — I'll add more details in an inline comment below |
ciampo
commented
Nov 26, 2021
Comment on lines
+50
to
+56
| expect( onChangeSpy ).toHaveBeenCalledWith( '2018-12-22T00:00:00' ); | ||
| onChangeSpy.mockClear(); | ||
|
|
||
| fireEvent.change( minutesInput, { target: { value: '35' } } ); | ||
| fireEvent.blur( minutesInput ); | ||
|
|
||
| expect( onChangeSpy ).toHaveBeenCalledWith( '2018-12-22T12:35:00' ); | ||
| expect( onChangeSpy ).toHaveBeenCalledWith( '2018-12-22T00:35:00' ); |
There was a problem hiding this comment.
The fix introduced in this PR caused this unit test to fail. After looking more into it, I believe that the unit test was previously wrong:
- the time picker in the test is using the 12 hours period
- the initial time set to the picker is
1986-10-18T11:00:00, and therefore the picker automatically picksAMas the period - the period is not changed explicitly throughout the test
- the
hoursinput's value is changed to12(remember, the period is still set toam) - the test currently expected
12amto be converted to midday - the test was passing until now because of the lack of value adjustment prior to this PR
I believe that it is correct to update the unit test in this case, since 12am represents midnight and therefore should be converted to 00 in the 24h format
7 tasks
ntsekouras
approved these changes
Nov 26, 2021
Comment on lines
+50
to
+56
| expect( onChangeSpy ).toHaveBeenCalledWith( '2018-12-22T00:00:00' ); | ||
| onChangeSpy.mockClear(); | ||
|
|
||
| fireEvent.change( minutesInput, { target: { value: '35' } } ); | ||
| fireEvent.blur( minutesInput ); | ||
|
|
||
| expect( onChangeSpy ).toHaveBeenCalledWith( '2018-12-22T12:35:00' ); | ||
| expect( onChangeSpy ).toHaveBeenCalledWith( '2018-12-22T00:35:00' ); |
There was a problem hiding this comment.
This is testing well for me, too. Thanks for fixing it up and adding in the extra test @ciampo!
noisysocks
removed
the
Backport to WP 6.7 Beta/RC
noisysocks
pushed a commit
that referenced
this pull request
Nov 29, 2021
* DateTimePicker: Extract `from12hTo24h` function * DateTimePicker: correctly convert hours from 12 to 24 format when updating the time * CHANGELOG * Only apply the value adjustment when the hours input updates * Add unit test to check setting hours with PM period selected * Update unit test on the assumption that 12am should be intended as midnight
ciampo
added
the
Backport to WP 6.7 Beta/RC
|
I've added the backport to WP beta/RC label in case it's not too late (cc @noisysocks ) |
|
I backported this on 29 November. You can tell if a PR was backported by checking if there's a commit in |
noisysocks
removed
the
Backport to WP 6.7 Beta/RC
That's great! And thank you for the clarification 🙇 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Fixes #29720
After some tweaking, the issue seems related to a bug in the
updatefunction. This function doesn't seem to take the period (AM/PM) into account, and therefore it sets the hours for the new datetime always as a number between 1 and 12 (while the new datetime expects a 24h format).This PR uses some existing logic for the "12h to 24h format" conversion also in the
updatefunctionA couple of notes:
How has this been tested?
Without this PR's code applied, setting an time with the
PMperiod results in theDateTimePickerforcing it back to theAMperiod. With this PR, setting a time in thePMperiod should work as expected.Can be verified in:
Screenshots
Before this PR: (when the component is using the 12 hour format and the period is set to PM, changing the hours always causes the period to automatically switch to AM)
datetimepicker-bug.mp4
With the fix from this PR:
datetimepicker-am-pm.mp4
Types of changes
Fix
Checklist:
*.native.jsfiles for terms that need renaming or removal).