Found date bug

[Lennert Stock]

Hi, I found the following bug: if I set the expiry date to say 2022-11-15, it showed up in the front end a day earlier, 2022-11-14. My time zone in WP is set to CET. I use the latest production versions of WP, WOO and this plugin.

I found and fixed the bug. Maybe it’s useful to you for a next release.

In includes/SOFT79_WCXD_View.php there’s this function:
public static function formatDate( $date )

It does this call:
$formatted = empty( $date ) ? ” : date_i18n( get_option( ‘date_format’ ), $date );

I changed it to this:
$formatted = empty( $date ) ? ” : wp_date( get_option( ‘date_format’) , $date, wp_timezone() );

Explanation:
date_i18n() takes a timestamp and handles it like a localized timestamp, not UTC. As I am in CET, it subtracts 1 hour from the timestamp to convert to UTC. But that timestamp ($date) was already UTC. If I pick 2022-11-15 in the datepicker (latest WP/WOO versions), it saves it as a UTC timestamp. So it unnecessary substracts 1 hour and midnight the 15th becomes 23:00hrs the 14th.

In date_i18n(), after converting to UTC, it then calls the wp_date() function. My change is just a copy of that call in date_i18n().

[Soft79]

Thanks for letting us know. I’ll take a look at this.

[Soft79]

I can’t reproduce this issue. We’re also on CET. Can you please temporarily add the following snippet to your child theme’s functions.php?

add_filter( 'soft79_wcxd_format_date', function ( $formatted, $date ) {
	SOFT79_WCXD()->log( 'debug', 'Date: ' . $date . ' formatted: ' . $formatted . ' timezone: ' . print_r( wp_timezone(), true ) );
	SOFT79_WCXD()->log( 'debug', 'date_i18n: ' . date_i18n( 'Y-m-d H:i:s', $date ) );
	SOFT79_WCXD()->log( 'debug', 'wp_date: ' . wp_date( 'Y-m-d H:i:s' , $date, wp_timezone() ) );
	return $formatted;
}, 10, 2);

This will log some info to “WooCommerce > Status > Logs” when the date is formatted on the frontend. Can you please send me such a log?

[Lennert Stock]

Here’s the output of a product with expiry 10 sep 2023 CET, seems correct:

Date: 1694296800 formatted: 10 september 2023 timezone: DateTimeZone Object ( [timezone_type] => 3 [timezone] => Europe/Amsterdam )
date_i18n: 2023-09-09 22:00:00
wp_date: 2023-09-10 00:00:00

[Soft79]

What is your PHP’s timezone? Please use date_default_timezone_get()

[Lennert Stock]

Europe/Amsterdam

[Soft79]

Ok, I see. I can reproduce it now. The issue is that we mix the PHP timezone and the WP timezone in our code and our test environment has UTC timezone set in PHP and Europe/Amsterdam in WP.

We’ll work on this.

[Lennert Stock]

Yeah I wondered about that on my setup. If I change WP timezone to say London, it still showed up Europe/Amsterdam in PHP. But my PHP ini has it set to UTC. Didn’t investigate further.

[Lennert Stock]

Found that bug in my setup, somewhere it sets the timezone to Amsterdam to calculate shipping time, but did not set it back to the original timezone (UTC), which is how it should be.

I fixed that and can confirm your code works fine then without the patch.

[Lennert Stock]

P.S. In wp-settings.php it does this:

// WordPress calculates offsets from UTC.
// phpcs:ignore WordPress.DateTime.RestrictedFunctions.timezone_change_date_default_timezone_set
date_default_timezone_set( ‘UTC’ );

Meaning that although you might still want to fix it for edge cases, it was really a bug at my end and a fix is not absolutely required in the plugin.

[Soft79]

I’ve implemented a fix. We now respect WP’s timezone when handling expiry dates.

Could you please try the fix on your end? Please download 1.5.0-dev.5 from your account page at https://www.soft79.nl/my-account/ .

[Author]

Posts