Date/Time cleared when saving post

[miglosh]

Hi Per,

I tried the date time picker on 8 different WP4 installations - with the free ACF 4 and the latest ACF 5 pro version - and am having always the same problem - whatever browser I use:

After choosing date and time, when I click Update to save the post, the date/time field gets cleared and thats it...

Do you have any recommendations?

Best regards,
Miglosh.

[LeBenLeBen]

Exact same problem here, the field gets cleared on save and nothing is saved to the database.

Using 2.0.18.1 with ACF 4.3.9

[LeBenLeBen]

The problem seems to be related to the date format.

With the following format, it works well:

dd/mm/yy

But if I put something like:

DD d MM yy

The value remains unsaved although this format is perfectly handled by the date picker.

[miglosh]

Actually, I got it running now. The problem was not the GitHub version of the plugin - that one is definitely working for me.
As I found out, it is only the version downloaded from the ACF website that's making problems...

Cheers to GitHub :-)

[soderlind]

@miglosh, where on the ACF site ? http://www.advancedcustomfields.com/add-ons points to the WordPress Plugin Directory, and the plugin there is in sync with github.

[eric-the-viking]

I am experiencing the same problem. But just with a single post from a custom post type. I am going to try the github version of the plugin as well and will be reporting back in.

Alright, update guys: Using the GitHub version does not change anything for me. As @soderlind said, the versions are in sync. But it seems to be a problem with the date format. Changed it from dd. MM yy to dd.mm.yy did work.

[elomatreb]

Hello,

I too experienced this problem, not even changing the date fixed it for me. I experimented a bit with my site and found out this only seems to occur when using a translated version of WordPress (I was using the German one), not with the default English.

I am using WordPress 4.1 and ACF 4.3.9.

[timbakkum]

I also have a similar bug and am using a french version of wordpress. I described my setup here :
#85 (comment)

any ideas on how to fix this issue ?

[kokomomtl]

Same issue here, using french version of wordpress. This is sad since this setup is probably one of the only ones that worked with WPML without having any serious issues. Has anyone tried reaching out to the original dev to see if he plans on supporting it or at least giving the project to someone else?

[kokomomtl]

For those stuck with this bug and looking for a temporary solution, what I did was I created a seperate am/pm select in ACF and displayed that instead. Not the most elegant solution but at least I didn't have to change the whole system.

[sternhagel]

Experienced the same problem today with the latest version of the plugin (2.1.1) - also with a translated Wordpress installation (German).

After some debugging I think I found the reason - it's in the function update_value in date-time-picker-v4.php

Before updating the database, the formatted date-time string gets parsed by strtotime in line 346:
$value = strtotime( $value );

This works fine for English language date-time strings, as described in the PHP documentation. However, strtotime() doesn't support non-English text strings, so when you're using a date format with non-English month labels (e.g. "3. März 2017 08:45"), strtotime() returns FALSE, and nothing is written to the database, and so the date field remains empty.

Unfortunately I couldn't find a clean and easy fix for this - the only solution I could find was to use strptime() and mktime(), and do something like this instead:

$date_array = strptime( $value, "%d. %B %Y %H:%M" );
$value = mktime( $date_array['tm_hour'], $date_array['tm_min'], 0, $date_array['tm_mon'] + 1, $date_array['tm_mday'], $date_array['tm_year'] + 1900 );

To make this a universal solution the format string for strptime() have to be converted dynamically from the jQuery format strings, so we need two more functions like js_to_php_dateformat() and js_to_php_timeformat() to convert to the strftime() format, which is different from standard PHP format unfortunately.

In my install I also had to set the PHP locale explicitly, but I'm not sure if this is a general problem or related to the hoster's PHP configuration. In my case, the solution was putting the following as the last line in wp-config.php:
setlocale(LC_ALL, 'de_DE.UTF8');

UPDATE: there's a pull request to fix this issue here: #109