Use current time setting for the timestamp widget

I noticed this same thing. Note the scenario here happens if the field is not required.

+1 for the idea of adding a field setting. I came to the same conclusion in #2978467: Timestamp field widget - "Leave blank to use the time of form submission." is inaccurate if field is required.

@tea.time :wave:

OK, moving this to datetime.module. It's not part of that module proper, but related.

Since this is a bug report, we need a test to demonstrate the bug. There are also BC issues around adding a setting. And I think we have only minimal testing on the item and widget...

A lot of this stems from making this field exposed to the UI, instead of just being a base field. It was originally used as a common point for ChangedItem and CreatedItem, and then exposed in #2707057: Remove no_ui from timestamp field type.

So, I think we need to figure out the subtleties of fixing a bug and adding a new feature (which may be the true way to fix the bug).

Updated datetime_timestamp field Widget

Another way of doing that create your own field widget and apply that widget on field.

@sahil432 #8 demands for test cases.
Apart from it

+++ b/core/lib/Drupal/Core/Datetime/Plugin/Field/FieldWidget/TimestampDatetimeWidget.php
@@ -35,7 +35,7 @@ public function formElement(FieldItemListInterface $items, $delta, array $elemen
+    $element['value']['#description'] = $this->t('Format: %format. Leave blank if you don\'t want to set any value.', ['%format' => Datetime::formatExample($date_format . ' ' . $time_format)]);

How you write don't ?

I have 2 timestamps. The 2nd one is only needed if an event runs more than 1 day.
So most of the time, I don't want the 2nd timestamp to display, ONLY when it's filled in.
But both timestamps always display, because the timestamp autofills itself with the date that I created it, when it's left empty.
What can I do to stop this?

EDIT: This worked for me:
{% if content.field_date_finish[0] is empty %}

{{ node.field_date_start.value|date("d/m/Y g:i A") }}

{% endif %}

{% if content.field_date_finish[0] is not empty %}

{{ node.field_date_start.value|date("d/m/Y g:i A, e") }}
  -  
{{ node.field_date_finish.value|date("d/m/Y") }}

{% endif %}

The problem is even more drastic when using a multivalue field.
Let's say you have a Timestamp field with unlimited values.

On every entity save it creates a new item for the timestamp field, because of that behavior.

This also happens when you edit the fields settings with Field UI. There we have the "Default value" settings and on every time when saving the field settings it creates a new item for the default value.

Rerolled the patch for 9.2.x, I agree with #21, and added some logic to the patch given in #2.
I tried to fix the unwanted behaviour raised by #18.
Added a tests to verify the behaviour of "use_current_time" settings.

Please review.

Fixed one Cspell issue.

When I used the patch from #25 I noted that the "created" field on nodes was reset to the current date even though the field was already set.

Hi,

I was able to recreate this issue with a time stamp field in Drupal 10 latest dev and below. There is a ticket to sort out UX for date related fields, widgets and formatters. https://www.drupal.org/project/drupal/issues/2897397

I believe the consensus will be to allow this widget to work exactly the same as the Date time widget (can they use the same widget??).

TODO:
Patch still needs testing / tests to pass.

Added reroll of patch #25 on Drupal 10.1.x.

Try to fix PHPStan Errors.

The config schema was in the wrong place, causing it to not be used. I started a MR based on the last patch and fixed this issue there.

fix conflict on 11.x

Hi @joey91133,

Getting error while applying MR.

moving back to NW.

After MR:

@djsagar
This is a bug on gitlab.
You should use .diff file not .patch.
I don't know why gitlab will cache patch file on MR.

With a schema change going to need an upgrade path + tests around that.

Issue summary will also need to be updated to use standard issue template. With a UI change we probably need a change record.

Used the 4681 MR to update the patch so it applies on Drupal 10.2.x.

#46 doesn't apply for me with Drupal 10.2.7 so here's a re-roll

I rebased the MR against 11.x and fixed an issue where the field value was always overwritten, even if the field already had a value.

There was a fatal error when submitting an empty value. Fixed the error and added some test assertions to check this scenario.

Reroll (Merge request !4681) for 10.3.9

Patch #51 works for me using Drupal 10.3.9

I've just released a module that implements the date/time fields in a different way.
It also supports HTML5 elements in views exposed forms
https://www.drupal.org/project/date_point

I think I've fixed the TimestampTest by ensuring that $this->fieldName gets set. I still see a lot of tests failing but none of them relate to the timestamp widget.

BTW hi @man-1982 long time no see (:

Open tags still seem needed

Actually missed one as upgrade path will need test coverage

@smustgrave Thanks for your checks. I've updated the issue description to try and conform to the current template. I don't know much about upgrade path tests but I'll try and figure this out while I'm working on this issue.

I might also see about adjusting the MR and tests further to add functionality. I'd like to ensure we've got an "on demand" setting that lets the field remain empty as long as we need it to.

Issue summary updated as of #60.

The Date Point module mentioned in #53 perfectly resolves this issue and others:

• Blank values are possible for non-required fields
• Views filters compares against current time using semantically friendlier "now"
• Seconds can be disabled for the user
• Date and time are combined into a single input field

Since I'm starting a new project, I will opt for this module rather than patched core fields.

I've just found this alternative module which try solve the core bug: https://www.drupal.org/project/timestamp_nullable