Incorrect time/date in WP-Crontrol schedule display screen

Thanks for the message, rrecurse.

I have a suspicion that there might be a bug in WordPress core in play here, because I’ve checked this functionality before and it’s definitely correct as it currently stands. Events stored in the cron schedule are stored with a GMT timestamp, so the correct offset needs to be applied in order to display the time according to the local timezone.

Would you do me a favour and do two small checks for me please?

1. Add a future event for a specific time and then check whether the correct time is displayed in the event list? For example, add an event with a time of 2016-09-01 01:23:45 and then let me know what time appears next to the event.
2. Let me know if the UTC time and Local time displayed below the cron event table are both correct.

Thanks in advance.

Hi John,

Both UTC time and local time summary below event schedule table show correct times. The display issue seems limited to the event lines which use the get_date_from_gmt() function.

Using the date/time you suggested (2016-09-01 01:23:45), upon saving a job called test_cron, the date/time displays as 2016-08-31 21:23:45

As you suggested, the function get_date_from_gmt() inside /wp-includes/formatting.php must be the culprit.

Notice line 2984 of /wp-includes/formatting.php:

$datetime->setTimezone( new DateTimeZone( 'UTC' ) );

I’d have to thoroughly test this hunch, but I suspect it’s setting the time zone to UTC AFTER already setting time zone with $tz. Perhaps only trigger the timezone reset to UTC if $tz is not defined:

if(empty($tz)) {
    $datetime->setTimezone( new DateTimeZone( 'UTC' ) );
}

Since you’re using a core wp function (get_date_from_gmt()), why not swap to the suggested date_i18n() function and call it a day?

Worked for me.

Hey, Worked for me, too!!
Great share, save my life ??

Thanks for looking into that, rrecurse.

So in this case, the displayed time is actually correct, because the Next run (UTC) input expects a UTC time. That said, this might not be very clear to the user. If you enter a time such as +2 hours, it also works as expected.

So, the question is, are your other cron jobs showing the correct time? Or are the only “incorrect” times the ones that you enter when manually adding a cron job with an explicit time?

I think the fix here is to either: 1. make it even more clear that the input expects a UTC time, or 2. make the input expect a time using the local timezone.

Hi John,

All scheduled tasks in the table list show incorrect offsets. Even ones scheduled by script (e.g. wp_schedule_event). If I mind the UTC time when entering the task, the display time in that table is still off by an additional GMT offset.

If I enter in your example time of:

2016-09-01 01:23:45

…it displays:

2016-08-31 21:23:45.

I think an idiot-proof solution is having a date/time js calendar to select schedule times in human readable format, and have display times reflect the times entered with said calendar. The actual event would be scheduled correctly in the background while admin-user will see human readable local time.

I also don’t think the logic in function get_date_from_gmt() is accurate. Why apply the TZ to the time if $tz is not empty/null. It seems to be taking the time, after offset and reapplying the offset found. But that is a core wp function and probably outside the scope of your plugin.

The confusion here seems to be that all of WordPress’ cron functions expect a Unix timestamp, which uses UTC time, but the documentation of the wp_schedule_event() and related functions don’t make this clear.

If I enter in your example time of:

2016-09-01 01:23:45

…it displays:

2016-08-31 21:23:45.

This is correct behaviour, as the time entered expects a UTC time (the same goes for the $timestamp parameter of wp_schedule_event()). In your case, UTC is 4 hours ahead of your local time.

The behaviour of get_date_from_gmt() is correct, as its description is: “Converts a GMT date into the correct format for the blog”. The timestamps that WP Crontrol passes through get_date_from_gmt() are all GMT (UTC) timestamps.

I think the clearest thing to do is to change the behaviour of the “Add Cron Event” functionality in WP Crontrol to expect a time in the local timezone, not UTC.

I’ve fixed the ambiguity over dates in WP Crontrol by switching the date input to expect a date in the site’s local timezone (with the addition of a native date and time picker for browsers that support it).