[Bug] datetime edit value

[adriallongarriu]

Bug report

What I did

I have a crud with a datetime input. On the create all ok but on edit the input force me to match the seconds of the value saved on create if i change the seconds the value is invalid and the form dont send.

CRUD::addField([
            'name' => 'publish_on',
            'label' => __('backend.events.publish'),
            'type' => 'datetime',
            'wrapperAttributes' => [
                'class' => 'form-group col-md-6',
            ],
        ]);

What I expected to happen

Change value and send the form.

What happened

If i try to edit the secons the input is invalid and i can't send the form and save new value.

What I've already tried to fix it

I override the view datetime and add step="1" to the input

[backpack-ai-bot]

Kappa Answer:

The knowledge sources don’t mention this exact “seconds must match or input is invalid” behaviour, so I can’t confirm a known Backpack bug for it. I can only rely on what is documented about the datetime field.

A few relevant points:

1. datetime is a native browser field
   The datetime field in Backpack is just:

   CRUD::field([
       'name'  => 'start',
       'label' => 'Event start',
       'type'  => 'datetime'
   ]);

   which renders an HTML input type="datetime-local"> and is therefore browser‑dependent. [datetime field]

   Different browsers can be strict about the format (including seconds), and that can cause “invalid” input states.

2. Model casting / mutator requirement
   Docs explicitly say that if you use datetime casting on the model, you should add a mutator to correctly parse the browser’s datetime-local format: [datetime field]

   public function setDatetimeAttribute($value) {
       $this->attributes['datetime'] = \Carbon\Carbon::parse($value);
   }

   (Replace datetime with your attribute name, e.g. publish_on.)

   If your model has casts/$dates for publish_on but no matching mutator, you can get format issues when editing. [datetime bug]

3. Workaround / alternative

   • Ensure your model has a proper mutator for publish_on if it’s cast as a date/datetime.
   • If the browser behaviour is still problematic, Backpack recommends using the datetime_picker field when you need consistent, browser‑independent behaviour: [datetime vs picker; datetime_picker field]

   Example:

   CRUD::addField([
       'name'  => 'publish_on',
       'label' => __('backend.events.publish'),
       'type'  => 'datetime_picker',
       'datetime_picker_options' => [
           'format' => 'YYYY-MM-DD HH:mm:ss',
       ],
       'allows_null' => true,
   ]);

Because the sources don’t describe your exact “seconds must match” issue, I can’t point to an official fix beyond these documented recommendations. If adding the mutator and/or switching to datetime_picker doesn’t solve it, it’s likely a browser‑level validation quirk rather than a documented Backpack bug.

ℹ️ Please note our AI Bot does not reply to follow-ups, this will be the only AI answer in this thread. If the AI helped you find the answer, please mark it as answered or write details below so it can learn. Then close the conversation. If not, please give more information for when a human reads this. ℹ️

Relevant sources:

Github Issue (closed): Datetime picker field is broken
CRUD - Datime - Chrome - Firefox
Fields|datetime_picker PRO
Github Issue (closed): DateTime Picker error when date deleted after being set
Fixing undesired value on datetime inputs
Fields|datetime_picker PRO
Github Issue (closed): datetimepicker is not keeping the old values
Github Issue (closed): defaultDate in datetime_picker overwrites existing value
Github Issue (closed): [Bug] Datetime picker translation
Github Issue (closed): addField datepicker not working properly
Github Issue (closed): [Bug] datetime field breaks when using $dates/$dateFormat/$casts
Github Issue (closed): Date Time Picker Can't Edit

[backpack-ai-bot]

CrawlChat Answer:

I don't have specific documentation available in my knowledge base about this datetime edit validation issue. However, based on your bug description, here are some suggestions:

The problem appears to be that the datetime field is enforcing strict validation on the seconds value during edit. Since adding step="1" to the input didn't fully resolve it, you might also try:

• Check validation rules: Verify if there's a custom validation rule on the backend that's comparing the exact datetime format including seconds
• Inspect the datetime format: Ensure the format stored and the format expected on edit match exactly
• Override the validation: Add a custom mutator or validation override in your model to handle datetime parsing more flexibly
• Check Backpack version: This might be version-specific, so ensure you're using the latest patch

For a more targeted solution, I'd recommend reaching out to the support team with details about your Backpack version and any custom validation logic you might have in place. They can help identify if this is a known issue or provide a specific fix for your setup.

ℹ️ Please note our AI Bot does not reply to follow-ups, this will be the only AI answer in this thread. If the AI helped you find the answer, please mark it as answered or write details below so it can learn. Then close the conversation. If not, please give more information for when a human reads this. ℹ️

Relevant sources:

How to add date filter with relationship_count? · Laravel-Backpack/community-forum · Discussion #1292 · GitHub
New Addon - Editable Columns :: Backpack for Laravel
[Bug] Multiple values are sent incorrectly as subfield
Laravel Advanced: Caching - Explained Simply :: Backpack for Laravel
Upgrade Guide :: 7.x Docs :: Backpack for Laravel
[Bug] Repeatable field with belongsToMany relationship not saving data
Columns :: 7.x Docs :: Backpack for Laravel

[pxpm]

Hey @adriallongarriu thanks for raising the issue. It looks like this is a browser compatibility issue ?

I was not able to reproduce your issue using chrome 143.0.7499.147.

Did you try the mutator solution bot provided ?

If you are still experiencing issue I need you to provide me more reproduction steps, as the problem could go as far as what is the field type on the database, and what database system are you using.

Cheers