Hello, today I updated WordPress to 5.3 and tragically found out that it completely messes up any dates in “date_picker” fields inside a repeater, by shifting them all one day earlier: i.e. “20191114” becomes “20191113”. Some additional info I gathered through some debug on my local server:
– it happens only to dates inside a repeater field;
– the value is stored correctly inside the database; i.e. if I do a get_post_meta($post->ID, ‘repeatername_0_datepickername’, true) it returns 20191114 but with a while( have_rows(‘repeatername’) ): the_row() followed by a get_sub_field(‘datepickername’) it returns 20191113;
– the issue seems to happen during the filtering via the ‘acf_format_value’ function: I tried editing it by removing the line $value = apply_filters( “acf/format_value”, $value, $post_id, $field ); and it returns the correct value (of course that’s not a solution, I just tried doing that on my development machine to try and understand);
– this started happening an hour ago right after I updated to WP 5.3, nothing else was changed and I’m running the latest version of ACF Pro (5.8.7).
I also opened a ticket because this is a really urgent problem impacting on a lot of websites I made (right now I’m using a temporary solution which simply adds a day to the date in my script but of course it’s not optimal).
It’s NOT the same issue as https://support.advancedcustomfields.com/forums/topic/date-picker-control-not-working/ , my control works perfectly in the backend.
I just found out that the culprit seems to be I’m using the following instructions in another part of my script BEFORE running the while loop on the repeater field:
The point is that I’m in that timezone and I NEED to set it and the appropriate locale in order for other parts of my theme to work correctly and I don’t see why that should impact on ACF. Any clues?
Thank goodness for that, I though I was going mad. Exactly the same issue. All dates presented on front end a day behind but OK in back-end. Upgraded ACF and WordPress to latest versions so I don’t know which has caused this problem.
This is a football results website so is date crucial. Added dates to day and they are OK, it seems to be dates that were created prior to the upgrades. Re-saving doesn’t seem to solve it.
Update: I did some more research and found out that, after all, I’m not supposed to use date_default_timezone_set() with WordPress 5.3. As stated here https://make.wordpress.org/core/2019/09/23/date-time-improvements-wp-5-3/ :
“don’t change PHP time zone with date_default_timezone_set() (this one is hard requirement for correct core operation!)”
So I’m currently working on modifying my functions to work the proper way, by getting the ‘gmt_offset’ option and calculating it to process the current timestamp instead of changing the default timezone. That way ACF seems to work properly, too.
P.S. for a quick albeit unelegant fix, you can restore the timezone to UTC AFTER you do your stuff with your functions that use your specific timezone. So that’ll be
date_default_timezone_set( get_option(‘timezone_string’) );
…do your stuff…
I received this from support:
“The new wordpress update has brought some changes to date_i18n()
I believe the issue you are experiencing is due to a change in the
date_i18n() function causing values to be modified via the timezone setting.
This issue does not effect the value saved into the DB, but occurs when loading and “formatting” the value.
We have a few similar bug reports at this time, and will investigate this shortly.
For now, can you please try the following fix: Edit the file “includes/api/api-helpers.php” on line 4117 and change from:
return date_i18n($format, $unixtimestamp);
return wp_date($format, $unixtimestamp);”
Elliot here – ACF dev.
Thanks for the bug report. I am currently reviewing similar tickets both on our helpdesk and the WordPress trac. This issue looks to be related to the use of
date_default_timezone_set() within WordPress 5.3, and is not specific to ACF, but will also affect other parts of WP such as “scheduled posts’.
Please read this reply from one of the WordPress moderators: https://wordpress.org/support/topic/read-this-first-wordpress-5-3-master-list/#post-12124062
If my prediction is correct, the values saved into the DB (from our date related field types) should be correct. The problem occurs only when loading the value via
get_field() which will “format” the value via the
date_i18n() function, triggering the issue caused by the use of
Please let me know if you are able to resolve this issue by removing the
date_default_timezone_set() function from your theme / plugin. This will provide helpful feedback to myself and the WP team 🙂
As I said before, I had realized that date_default_timezone_set() was the culprit.
I removed every occurrence of it in my themes/plugins and made a function instead which takes a timestamp or a Ymd as an argument and returns several different date/time formats (also passed via an argument) taking into account the timezone offset from WP. Now I’m using my function instead of date() or strftime() in all my WP projects. Everything seems to run smoothly, including ACF Pro.
We don’t use
date_default_timezone_set() in our themes and are experiencing this issue.
When I try to set a date to 2nd May 2020 it saves the value correctly in the database, but displays it incorrectly (a day behind) in both the admin screen and the front end of the site as per Elliot’s explanation.
@geniusdivision – Thanks for the reply.
Can you please test out the following code in one of your theme template files and report back with the date displayed?
// Arbitrary date-time value. $time = strtotime('2019-11-18 08:30:00'); // Display date. echo date_i18n('F j, Y g:i a', $time);
@geniusdivision – Great. This is the correct value expected to be displayed. This same code is used in the ACF date, time and date-time fields to “format” the loaded value.
Can you please try the issue once more making sure to clear any cached data that could interfere with the results?
If the problem persists, I would like to take a look myself and debug the PHP on your site. To do this, please open up a new support ticket with all the relevant information: https://www.advancedcustomfields.com/contact/
@elliot — unfortunately this hasn’t fixed it.
I can replicate the issue with this process:
Here’s a quick video: https://www.dropbox.com/s/n7d3b1iyhyc7scd/1.%20Setting%20Date.mov?dl=0
It may help to know that we use https://roots.io/bedrock/ as a boilerplate for a better WordPress structure, but all our WordPress themes are built from scratch.
I tried changing the WordPress theme to a default one and I still experienced the same issue.
Happy to open up a new support ticket if this doesn’t help!
Just to further update — I will figure this out 😃
@elliot — I think I’ve narrowed the issue down to something to do with Bedrock.
A default install of WordPress with the default theme displays the date correctly from the datepicker field.
I’m now going to install a default version of Bedrock with a default theme and see what this returns.
I’m 99.99% sure the problem you are facing will be due to a
date_default_timezone_set() call in your theme, or other website filed (perhaps wp-config.php).
Please be sure to read this reply from one of the WordPress moderators: https://wordpress.org/support/topic/read-this-first-wordpress-5-3-master-list/#post-12124062
I’m (and I’m sure a few others) are a bit confused on exactly how to fix this issue.
Is this new behaviour to be worked around in the ACF plugin, so we should wait to for an update to ACF is released?
Or is there something we should be fixing? We don’t have anything in the functions file (our issue is on a bog-standard WP install)
It’s been some time since the WordPress 5.3 release, but it appears this timezone issue is still affecting ACF users. I sympathize for you, and hope the following info can help.
Unfortunately, this issue is not an ACF bug that can be fixed from our end.
The issue stems from a change in WordPress 5.3 that alters the behavior of the
date_i18() function. This function is used in ACF to “format” the saved value based on the field’s settings.
Since the update, WordPress now expects the default timezone to be UTC, which is causing a widespread incompatibility with the
Please read this comment: https://wordpress.org/support/topic/read-this-first-wordpress-5-3-master-list/#post-12124062
The only known solution is to remove any occurrence of the
date_default_timezone_set( ) function from your site. This should first be tested, as each website is different and may require additional changes to avoid timezone related date problems.
You may also find some useful info on this announcement here:
You must be logged in to reply to this topic.
Welcome to the Advanced Custom Fields community forum.
Browse through ideas, snippets of code, questions and answers between fellow ACF users
Helping others is a great way to earn karma, gain badges and help ACF development!
The ACF site is currently experiencing some issues.— Advanced Custom Fields (@wp_acf) September 21, 2022
We apologize for the inconvenience and we are working hard to get it back up and running as soon as possible.
© 2022 Advanced Custom Fields.