Skip Navigation

[Résolu] Date Field bug: on save, get error "Please enter a date after 1 January 1970"

Ce fil est résolu. Voici une description du problème et la solution proposée.

Problem:
Create a custom date field, No matter what date I choose from the datepicker (custom date field in a custom post type), when I save the content it always says "Please enter a date after 1 January 1970".
Solution:
the problem is in the Types file \types\library\toolset\types\embedded\functions.php, line 737~745:

/**
 * Checks if timestamp supports negative values.
 *
 * @return type
 */
function fields_date_timestamp_neg_supported()
{
    return strtotime( 'Fri, 13 Dec 1950 20:45:54 UTC' ) === -601010046;
}

In your webserver, the strtotime( 'Fri, 13 Dec 1950 20:45:54 UTC' ) return value:
-600992046
but it should be value: -601010046

There are 5 hours (18000) between above two values (-601010046 and -600992046), which produce the problem: Types can not save the timestamp into database.

It is different value from -601010046, that means your webserver can not return the correct timestamp value, you will contact your webserver provider to correct it.
Relevant Documentation:
http://php.net/manual/en/function.strtotime.php

This support ticket is created Il y a 7 années et 9 mois. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

No supporters are available to work today on Toolset forum. Feel free to create tickets and we will handle it as soon as we are online. Thank you for your understanding.

Sun Mon Tue Wed Thu Fri Sat
- 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 -
- 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 -

Supporter timezone: Asia/Hong_Kong (GMT+08:00)

This topic contains 16 réponses, has 2 voix.

Last updated by Sanny Il y a 7 années et 9 mois.

Assisted by: Luo Yang.

Auteur
Publications
#413907

No matter what date I choose from the datepicker (custom date field in a custom post type), when I save the content it always says "Please enter a date after 1 January 1970".
But the date I choose is of course is past that.
When I pick a date, the date is shows as eg. July 7, 2016 in the edit screen.
The date format of the site (from WP settings) is j F Y, if that's any use to you.

The field is not required, nor I checked the verification box for the field.

Please advise, thank you.

#413918

Also, I noticed that when I try to show the date in frontend (even if it didnt save in the post editor because of the error above), I get:

"Fatal error: Call to undefined function wpcf_admin_validation_messages() in /var/www/vhosts/mysite.com/httpdocs/wp-content/plugins/types/library/toolset/types/embedded/classes/validation.php on line 41"

#413995

Dear Sanny,

It is abnormal, I can not duplicate same problem, please try this:
1) deactivate other plugins and switch to wordpress default theme, and test again
2) Enable PHP debug mode, copy and paste the debug logs here
PHP Debugging
In case you think that Types or Views are doing something wrong (what we call a bug), you should enable PHP error logging. Again, edit your wp-config.php file and add the following:

ini_set('log_errors',TRUE);
ini_set('error_reporting', E_ALL);
ini_set('error_log', dirname(__FILE__) . '/error_log.txt');
This will produce a file called ‘error_log.txt’ in your WordPress root directory. Make sure that the web server can create and write this file. If it cannot, use an FTP program to create the file and make it writable to Apache (normally, user www-data).
https://toolset.com/documentation/user-guides/debugging-types-and-views/

#414202

Nothing gets posted in the error log. The only errors are from the frontend.
"mod_fcgid: stderr: PHP Fatal error: Call to undefined function wpcf_admin_validation_messages() in /var/www/vhosts/mysite.com/httpdocs/wp-content/plugins/types/library/toolset/types/embedded/classes/validation.php on line 41"
I only use Types on this site btw.
Could you please check?

#414367

I can not duplicate same problem, please setup a test site with same problem, and fill below private detail box with login details and ftp access, also point out the problem page URL, I need a live website to debug, thanks

#414616

Also noticed that in the settings page of the maintenance plugin, in the backend, I get this error:

Warning: Missing argument 2 for wpcf_admin_add_meta_boxes() in /var/www/vhosts/mysite.com/httpdocs/wp-content/plugins/types/library/toolset/types/embedded/admin.php on line 102

Dont understand why, since it has nothing to do with Types or any custom field....

#414997

I tried these:
1) Export the Types setting file from your website to below test site:
hidden link
user/pass: xgren/111111

2) In the wordpress setting page:
hidden link
use same setting as your website:
Formato data: j F Y
Formato ora: G:i
Lingua del sito: Italiano

3) create a test post, and setup the custom date fields value:
hidden link
It works fine

Then I checked your webserver settings, you are using
PHPVersion 5.4.16

But according to wordpress document:
https://wordpress.org/about/requirements/
To run WordPress we recommend your host supports:
PHP version 5.6 or greater

So I suggest you upgrade the PHP to 5.6 or greater, and test again.

#415136

I updated to PHP 5.6.23
I tested with that and Twenty Sixteen.
Same issue.

Please advise.

#415150

I also tested disabling all plugins. Same issue.
Feel free to test on the website itself, it's not in production yet.

#415408

I checked again in your website, for example this post:
hidden link

custom date field "Data Fine / Scadenza", it can save values, and works fine, could you confirm it? thanks

#415462

Hi, it works now because I commented one part of the function that was causing the PHP error:

echo types_render_field("data_inizio");
 Fatal error: Call to undefined function wpcf_admin_validation_messages() in /var/www/vhosts/site.com/httpdocs/wp-content/plugins/types/library/toolset/types/embedded/classes/validation.php on line 41
    
 types/embedded/classes/validation.php

function filter_field( $field ) {
        if ( $field['type'] == 'date' ) {
            if ( !fields_date_timestamp_neg_supported() ) {
                if ( !isset( $field['data']['validate'] )
                        || !is_array( $field['data']['validate'] ) ) {
                    $field['data']['validate'] = array();
                }
                /*$field['data']['validate']['negativeTimestamp'] = array(
                    'active' => 1,
                    'value' => 'true',
                    'message' => wpcf_admin_validation_messages( 'negativeTimestamp' ), // bugged function?
                );*/
            }
        }
        return $field;
    } 

After commenting that part, everything seems to work fine, back and frontend.

Please make sure that it gets checked in the next version, clearly something doesnt work right there.

#415771

Thanks for the details, the problem is in the Types file \types\library\toolset\types\embedded\functions.php, line 737~745:

/**
 * Checks if timestamp supports negative values.
 *
 * @return type
 */
function fields_date_timestamp_neg_supported()
{
    return strtotime( 'Fri, 13 Dec 1950 20:45:54 UTC' ) === -601010046;
}

In your webserver, the strtotime( 'Fri, 13 Dec 1950 20:45:54 UTC' ) return value:
-600992046
but it should be value: -601010046

There are 5 hours (18000) between above two values (-601010046 and -600992046), which produce the problem: Types can not save the timestamp into database.

It is different value from -601010046, that means your webserver can not return the correct timestamp value, you will contact your webserver provider to correct it.
hidden link

#415862

I use other PHP time functions in the website, and the results are all good: timestamp is always correct for our timezone, format and offset.

If you convert the timestamp -601010046 here hidden link, you will get Fri, 15 Dec 1950 20:45:54 GMT, which is not equal to what your function expects.

From hidden link

Note:

Dates in the m/d/y or d-m-y formats are disambiguated by looking at the separator between the various components: if the separator is a slash (/), then the American m/d/y is assumed; whereas if the separator is a dash (-) or a dot (.), then the European d-m-y format is assumed. If, however, the year is given in a two digit format and the separator is a dash (-, the date string is parsed as y-m-d.

To avoid potential ambiguity, it's best to use ISO 8601 (YYYY-MM-DD) dates or DateTime::createFromFormat() when possible.

Using this function for mathematical operations is not advisable. It is better to use DateTime::add() and DateTime::sub() in PHP 5.3 and later

Also read the comments in that page. Using that format, in your functions, is NOT advisable.
Please modify the function to accomodate different server setups and locale settings.

#416127

Those are different time format, please check the difference between UTC and GMT here:
hidden link

And you can simple search with keywords "strtotime online" in google, and click the first link:
hidden link
input the value into field $time "Fri, 13 Dec 1950 20:45:54 UTC"
you will get the result "-601010046", it is same as the Types function;
fields_date_timestamp_neg_supported
https://toolset.com/forums/topic/date-field-bug-on-save-get-error-please-enter-a-date-after-1-january-1970/#post-415771

But as I mentioned above in your website the function:
strtotime( 'Fri, 13 Dec 1950 20:45:54 UTC' ) return value: -600992046

I suggest you ask help from your webserver providers.

#416682

I have checked server time and it was pointing to about 4-5h behind.
I have made sure that server timezone is correct in the php.ini and set the php to correct timezone in code too.

Can you please check again why all dates work fine in the website, except for Types date check?
I dont understand what could be wrong.
You can check the footer calendar code, it works with pure php dates and it's working perfectly good.

I had to comment again that part of the code from the validation.php file, feel free to put it back to test things.

Thank you

This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.