Tessa Watkins

Thank you for the quick update! Will this flag up as an automatic update of the plugin or should I update the plugin on my site manually with this changeset?

Thanks! You totally didn’t have to help me debug my problem, so thank you! I am using a lot of strtotime for sending dates through an API and displaying dates in an email. Sometimes the timezone just isn’t set, or defaults to UTC, when called on the page vs an AJAX call vs the cron event. I’ve since replaced all of my usages of that with a call to this function. It’s not the most glamorous piece, but it’ll do for the time being. Or if I find another bug in it. Which, as we know, I probably will since I only wrote it in a few hours lol. I’m more or less posting it here in case somebody with a similar issue comes across this thread (replacing prefix with whatever, and placed in theme’s functions.php file).

function prefix_strtotime($time = 'now', $now = false, $timezone = false)
{
    if ($now === false) {
        //If relative date isn't specified, default to now
        $now = time();
    }
    $date_offset = intval(date('Z')); //Returns an integer value like -14400 to use in timestamp offsets
    $wp_offset = get_option('gmt_offset') * 3600; //Returns a float value like (-4), multiply it by 3600 seconds per hour to use in timestamp offsets
    if ($date_offset != $wp_offset) {
        //The timezone is not set, so set it and fix it
        date_default_timezone_set(get_option('timezone_string'));
        $timestamp = strtotime($time, $now);
        if ($timezone === false) {
            //Modify the timestamp with WordPress timezone offset
            $timestamp += $wp_offset;
        } elseif (is_int($timezone)) {
            //Modify the timestamp with the passed offset
            $timestamp += $timezone;
        }
    } else {
        //Timezone offsets are the same, no need to bother with converting
        $timestamp = strtotime($time, $now);
        if( is_int( $timezone ) ) {
            //But a timezone offset was specified, so figure out the diff and then modify it back
            $timestamp -= ($timezone - $wp_offset);
        }
    }
    return $timestamp;
}

And for my usage:

date('m/d/Y g:i:s A T', fc_strtotime());//Displays current time in WordPress's timezone
date('m/d/Y g:i:s A T', fc_strtotime('2020-05-04 17:00:00', false))//Displays this time as if it was WordPress's timezone
date('m/d/Y g:i:s A T', fc_strtotime('2020-05-04 17:00:00', false, 0))//Assumes this time is set in WordPress's timezone, and displays it in UTC

• This reply was modified 6 years, 1 month ago by Tessa Watkins.
• This reply was modified 6 years, 1 month ago by Tessa Watkins.

I’m using WordPress version 5.4. In my site’s general settings, it’s set to New York and says this:
Universal time is 2020-04-30 00:30:06. Local time is 2020-04-29 20:30:06.

The “Site time” at the bottom of the cron events page says this:
Site time: 2020-04-29 20:31:39 (America/New York, UTC-4)

So yes, that indeed matches my site’s timezone settings. However, one of the hourly cron events I have running says this in the “Next Run” column:

2020-04-29 16:38:41
7 minutes 3 seconds

As we just discovered, it should display 20:38 for the time, not 16:38. This just might be my personal preference though. It’s certainly not a deal breaker for me as I’ll continue to use your plugin for all my cron managing needs, haha.

Edited: Though, I just realized that if it was displaying in actual UTC in the “Next Run” column, then it should be 00:38 if the next run is in 7 minutes (as of the time I copied/pasted), so 16:38 is still wrong. Maths in the wrong direction!

• This reply was modified 6 years, 1 month ago by Tessa Watkins.