After 2.1.1 update all time fields are treated as required; empty values not accepted.

Created The patch Fixed the issue. Please review

The last submitted patch, 4: 3423941.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

You patch is not good, it's basically partially reverting what was added in 🐛 Time Field fails required field validation if value is 00:00 Needs work .

Furthermore, just tested this on D10.1.9 and for me this is working fine.

- Added a Time Range field to article (not required)
- Add content, only fill in title --> Save
- No issue
- Add content, fill in title, Start time 12:00, end time 00:00 --> Save
- No issue
- Add content, fill in title, Start time 00:00, end time 12:00 --> Save
- No issue
- Added a Time Range field to basic page (required)
- Add content, only fill in title --> Save --> Validation constraint (OK!)
- Add content, fill in title, Start time 12:00, end time 00:00 --> Save
- No issue
- Added content type
- Added a Time Range field to article (not required, multi value)
- Add content, only fill in title --> Save
- No issue

Did you clear the cache after updating the module? Hiding the patch as it should not be used.

Yes, I cleared the cache. You can see the results of my test in this screenshot:

Also, when I inspect the time field, I see that the input element has a default value that is not parsable:

Having discovered that the module is interpreting the timestamp of 86401 as empty, I was going to submit a patch, but I see there's a lot of logic built around using that timestamp to indicate an empty value. I'm curious about that decision. What's the thinking behind it? I'm going to hold off on submitting anything in the meantime.

The reasoning behind that was explained in https://www.drupal.org/project/time_field/issues/3074674#comment-14872771 ✨ Support empty time range values Fixed and https://www.drupal.org/project/time_field/issues/3074674#comment-14874717 ✨ Support empty time range values Fixed

I picked a value that would not normally be used. So 60 seconds * 60 minutes * 24 hours = 86400 seconds in a day.

I then added 1 to that value so that I knew it wasn't a valid value but could still be referenced. Probably better ways to do it but that was the original thought process.

What I don't understand is how that value ends up in your field as default value. Was this a node created before the upgrade? Also what version of Drupal?

Also just noticed that the field you're referring to in screenshot #9 is not a timerange field, but a time field with seconds.

Ok so that's the issue. The field validation is not working for the regular time field. The tests I wrote only cover the timerange field.

Thanks for updating the empty field check logic, @BramDriesen. To answer your earlier questions (which you may not need now):

1. No, this was a 100% new node
2. I am using the most current version of Drupal, i.e. 10.2.3.

86401 is actually a valid timestamp, even if it's not likely to be used.

A valid timestamp yes, but not a valid time as it will fail in this function Time::createFromTimestamp($value);.

It's been a while, but if I remember correctly, in order to allow empty values in the timerange widget, we needed a numeral value in order to do the in-range check. I remember trying to use NULL or empty string but could not get that to fit the validation logic and actually work.

BramDriesen → credited Jan-E → .

Test

In my case (see related issue ✨ Support empty time range values Fixed ) it was also a time field. Moreover, it was intentionally hidden from some users by a hook_form_alter() statement:

$form['field_pmto_session_start_time']['widget']['#access'] = false;

Despite it being hidden the value that was entered into the database was 86401. No post-processing was done on the field, so I still do not know where the 86401 originated.

86401 was the new "empty" value being returned when nothing was filled in into the field. But the single timefield was not treating that value as empty resulting in the value getting saved.

Not sure if we need to add an update hook to clear the database of those entries.

I could reproduce the issue on a local copy of my site.
Then I applied your MR and did not run into the error 500 anymore.
If that count as RTBC, feel free to change the status.

With respect to an update hook to clear the values: it would be a tricky one, because you cannot change every 86401 value into 0. You have to actually delete the field instance and possibly also a revision instance.

Will tag a release as well.

https://www.drupal.org/project/time_field/releases/2.1.2 →

Automatically closed - issue fixed for 2 weeks with no activity.