I also encountered this issue, but it went a step further and was actively causing timezone issues with The Events Calendar (some spots would show the correct time while others would be left not showing the correct timezone [even for the same event; just depends on whether this plugin got in the way when rendering that output or not.])
Commenting out:
date_default_timezone_set( timezone_name_from_abbr( null, (int) get_option( 'gmt_offset' ) * 3600 , true ) );
to instead be:
//date_default_timezone_set( timezone_name_from_abbr( null, (int) get_option( 'gmt_offset' ) * 3600 , true ) );
in 99robots-custom-image-sizes.php on line 127 (as of version 1.2.8, anyway) appears to have fixed the vital timezone problems in The Events Calendar & also has WordPress’ Site Health screen no longer reporting a critical issue.
I’m guessing this may have adverse side-effects for other plugins (considering it’s important enough that Site Health is flagging it as a critical issue) while I can say it’s verified to not be good if you have The Events Calendar being used.
Meanwhile, what is this line of code even needed for? Why does/would a plugin that adds & manages additional add_image_size values & related elements on a site ever need to deal with time zones at any point?
Can this line of code just be removed in a future release, or what purpose was it serving where we need to consider alternative ways to address what it’s doing now without having the implementation break everything (I’ve left my version patched to simply not include that line of code & things seem to be working okay so far)?
Either way, this current implementation is actively breaking other plugins & is warranted in saying there’s a critical issue in what it’s doing. So whatever the fix ends up being, it should definitely be included in the next version of this plugin (so patched plugins don’t update to re-instate this bad behavior.)
