The datetime_timestamp field widget does not respect the field's default value or default value callback. Instead, the entity form's date + time widgets are left empty and the current time is saved to the field if one is not provided.
This change was introduced in 10.2.1 in #2791693: Remove sample date from date field error message and title attribute with a check in TimestampDatetimeWidget::formElement() to only use the field item delta value if the entity is "not new": https://git.drupalcode.org/project/drupal/-/commit/5404ebfb11155b53dee0e...
timestamp field eg: timestamp_test, to an entity.timestamp_test field, eg: 01/01/2024 - 12:00:00 AMdatetime_timestamp "Datetime Timestamp" widget.timestamp_test field does not use the configured default value.timestamp_test field.Do not check if the entity is new. Instead use the previous logic: If a field item delta value is set, use it to create a new drupal date time object.
Implement.
Add tests
Review
None
None
None
datetime_timestamp widget is fixed to respect field default values.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | 3414883-11.patch | 1.43 KB | paul121 |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes, plain diff MR !6187changes, plain diff MR !6185compare 
Comments
Comment #3
paul121 commentedComment #4
smustgrave commentedThank you for reporting.
Moving to 11.x as the current development branch, MR should be updated also.
This will also require test coverage.
Comment #8
acbramley commentedRecreated the MR against 11.x, please close your one @paul121
Comment #9
acbramley commentedApologies @paul121 I just saw you were fixing that branch at the same time.
Comment #11
paul121 commentedNo worries, I'll close that one. I won't have time to work on tests anytime soon.
Attaching a patch we can use in farmOS.
Comment #12
acbramley commentedI'll work on some tests
Comment #13
acbramley commentedAdded test coverage, fails with the following without the fix:
Comment #14
acbramley commentedComment #15
acbramley commentedComment #16
smustgrave commentedAs a regression this seemed higher to me.
Running the tests get the same as @acbramley does in #13
Was able to confirm the issue and that the MR fixes it.
Again as a regression believe it's good to mark now vs waiting a week.
Comment #17
quietone commentedCan you elaborate? Higher than what?
Again as a regression believe it's good to mark now vs waiting a week.I do not understand this. What happens in a week?
---
Thanks for the complete issue summary!
I compared the change here to the commit for the other issue and confirmed that it doing as stating in the proposed resolution.
I tested and confirmed the problem. Then, I applied the diff and ran the test, which does fail without the fix. The test could be added to \Drupal\FunctionalTests\Datetime\TimestampTest::testWidget() and would not interfere with that test. I am in two minds about that but will leave that for now.
Leaving at RTBC
Comment #19
catchI agree with this. If we add assertions to the test method, we save an entire Drupal install, which can make a meaningful difference to gitlab ci runtimes, so when it's easy to do that, it's worth doing.
Went ahead and made the change locally, ran the test, and pushed. Assuming the whole pipeline comes green I'll go ahead and commit this, since it's only deleting three lines or so.
Comment #23
catchCommitted/pushed to 11.x and cherry-picked to 10.3.x and 10.2.x, thanks!