Pods: DateTime field forces default value of time()

[nobleclem]

Describe the bug
When a Date/Time field used with no "Default Value" specified the field defaults to the current date/time (GMT if HTML5 and localtime if not).

To Reproduce
Steps to reproduce the behavior:
Assuming you extend the "Post" content type and have a Date/Time field with no default value and its not required.

1. Posts -> Add New
2. Save Draft
3. Refresh Edit Page
4. Value should be present in Date/Time field when none was entered.

This issue is more obvious if you enable html5 input for the Date/Time field but this happens on both input types. For the non-HTML5 input type the value immediately shows in the "hidden" input that follows the actual input of the field.

Expected behavior
If a Date/Time field is NOT required and no value is entered into the field then the value saved should either be 0000-00-00 00:00:00 or '' or NOT EXISTS.

Pods Version

2.7.16.2

Additional context
It seems as that the core of this bug has existed for some time but with two recent changes #5460 _(yes my issue and I must have missed this test case when testing the fix for it)_ & #5488 / #5528 which seems to have brought this to light. Until these two changes were made the raw issue never presented itself as a noticeable bug.

Possible Workaround
The only work around I have found was this:

add_filter( 'pods_form_ui_field_datetime_formatter', function( $datetime, $format, $date ){
    if( !$date ) {
        return false;
    }

    return $datetime;
}, 10, 3 );

along commenting out line 126 in ui/fields/datetime.php
$mysql_value = date_i18n( $mysql_format );

Possible Fix

The issues seems to be two files attempting to default the value to the current date time if no value exists. I have tested this fix in a dev environment and that seems to work. The workaround I am using in production while this bug exists.

remove lines 125-126 in ui/fields/datetime.php

} else {
    $mysql_value = date_i18n( $mysql_format );

change lines 719-721 in classes/fields/datetime.php
from

if ( empty( $date ) ) {
    $timestamp = time();
} else {

to

$timestamp = null;

if( !empty( $date ) ) {

[issue-label-bot[bot]]

Issue-Label Bot is automatically applying the label Type: Bug to this issue, with a confidence of 0.93. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[JoryHogeveen]

Hello @nobleclem
Could you please make sure your date/time fields allow empty values?

For the non-HTML5 input type the value immediately shows in the "hidden" input that follows the actual input of the field.
What do you mean?

[nobleclem]

Hi @JoryHogeveen

I have confirmed that for this date/time field that in "Additional Field Options" the "Allow empty value?" checkbox is checked.

As far as the "Non-HTML5 input" when that option for the date/time field is unchecked and you go to create a post and inspect the HTML you will see the actual element for the datetime field and right after it is another that is of type="hidden". That element which seems to be created by some javascript in the ui/fields/datetime.php file and upon page load of a "add post" that has a value even though the preceding is empty. Hopefully that clarifies things.

[JoryHogeveen]

@nobleclem
I've reproduced your issue and created a patch: #5538
Could you test this and verify it fixes the issue on your installation as well?

[nobleclem]

Patch looks great. Tested creating a new post with and without entering a datetime in both javascript and HTML5 based inputs for the datetime. Edited existing articles with a datetime entered as well as removed the datetime entered from an existing saved datetime.

[tomas-eklund]

OMG. I've spent two days debugging this issue and, when I finally figured what was going on, trying to write up a bug report. When searching for a similar ticket I only searched open issues.

Could an issue please remain open until the fix is actually released to the public?

[nobleclem]

This was just released in 2.7.17

[tomas-eklund]

This was just released in 2.7.17

Exactly, the update was offered to me today although the release date says yesterday. But this issue was closed 25 days ago. So when I was tripped up by the bug a couple of days ago there was no open ticket on the bug. (My fault for not searching closed tickets.) This resulted in me wasting two days debugging and trying to document my findings when the fix was already in place, waiting to be released. Two days I will never get back.

The takeaway is that I dove pretty deep into the code of Pods. An experience that scared me. I've given Pods a few chances - this might just have been the last.

[nobleclem]

Yeah I think it has to do with this bug turned into a pull request and that pull request had to go through the processes. I think the pods team was also working on other things so it took a while for this update to happen. Maybe its just a their process thing.

But yeah searching closed tickets is always a good thing. I spent a bit of time debugging this specific issue myself. Also spent the morning debugging a new bug with the new update. Beware of plugins magically being disabled.