Support » Plugin: Volunteer Sign Up Sheets » All times suddenly displaying GMT time?

  • Resolved the_webscaper

    (@the_webscaper)


    All of a sudden, all times displaying for tasks are 5 hours later than they should be – on multiple client websites.
    On the back end, viewing Edit Tasks, the times are entered correctly:
    http://prntscr.com/q2kqdy

    But as you can see they are showing on the website 5 hours later (GMT):
    https://www.neweaglepto.org/sign-ups/?sheet_id=105

    The time zone is set correctly in WordPress settings.

    Again, this is on multiple client sites so it’s not limited to this one site. It is possible this occurred when we updated plugins yesterday, though one client is telling me this started happening today, not yesterday.

    Even if this is not an issue with your plugin, can you please help me try to begin to troubleshoot this? Even if the server time is off, the WordPress settings should override that – I have no idea what could possibly be causing this.

    THank you in advance
    Kym

    The page I need help with: [log in to see the link]

Viewing 15 replies - 1 through 15 (of 20 total)
  • Plugin Author DBAR Productions

    (@dbar-productions)

    Sorry, I have no idea what’s going on, as I’ve never had any reports of anything like that happening, and I can’t reproduce the issue on my site. I played around with changing time zones, using different cities/countries, and also using several different UTC offsets, and everything still appears at the same time that I entered for the task.

    My plugin has no functions that would try to adjust the time by any kind of offset.

    I use the date_il8n WordPress function to format the time display the same way you have it setup in your WordPress settings. That function assumes any timestamp passed into it will already include any offset, and should not be trying to correct for any timezone differences. My plugin converts the text version of the date stored in the database to a timestamp (using the PHP strtotime function) before using the WordPress function, so there should be no adjustments of time zones happening.

    Here is the documentation for the WordPress date formatting function:
    https://developer.wordpress.org/reference/functions/date_i18n/

    If you look at the code for that function, WordPress does provide a filter hook before returning the result, which would allow other plugins to modify the result that is returned.

    My plugin has not been updated for a while, so if this was working fine yesterday, but then not today, then you need to look at what was changed overnight on your server, or your various WordPress installs. My code that displays the times hasn’t been changed at all for several years.

    Looking at the WordPress code for their date_i18n function, I see they did make an update with version 5.3 of WordPress, with this comment in the function:
    @since 5.3.0 Converted into a wrapper for wp_date().

    So, it possible that whatever they did, in conjunction with something very specific to your server, is somehow now causing their new wp_date function (which gets called from the old date_i18n function) to try to calculate a timezone offset.

    The other thing you could potentially look at is any new plugin your installed, or update, or possibly even a theme update, that is tapping into the filter hooks of those date/time formatting functions and also trying to do some type of time zone correction.

    Plugin Author DBAR Productions

    (@dbar-productions)

    Just for kicks, on my dev site, I tried changing all the date_i18n function calls to the new wp_date function, and then checked the times being displayed, and they were getting shifted based on the time zone I set. So, I reverted back to using the date_i18n function, and all is working well again.

    Double-check you have date and time formats set correctly, and timezone set correctly in your WordPress General settings, and then maybe save those settings again (in case something happened to overwrite those values somehow).

    As long as a format and timestamp are passed in, WordPress should not be trying to do any offsets for time zones, but the new function suggests that there were “quirks” in the old date_i18n function.

    Thread Starter the_webscaper

    (@the_webscaper)

    Thank you for the reply. I’m still at a loss for what I can do here. I tried changing the time zone to see what would happen; didn’t matter what time zone I set, the times were off by 5 hours (on one site. On another with this issue, it’s off by 6 hours). So the time zone in Settings doesn’t affect the display of time.

    My question – you said when you changed the code to the new format, it WAS displaying times based on the time zone. Wouldn’t that be preferable? If it’s not determining time by the time zone set in Settings, where is the time being pulled from? The server? (I know you explained it but I don’t quite understand). I’m not sure how to affect server time since these are shared hosting accounts, but that’s going to be my next stop, see if there’s anything the host can do?

    Thread Starter the_webscaper

    (@the_webscaper)

    Hm. This is odd. On ONE of my sites, if I change the time zone, the times displayed do vary (but still off by 6 hours). On the other site, changing the time zone has NO effect on the display.

    Really bizarre!

    Plugin Author DBAR Productions

    (@dbar-productions)

    No, I definitely do NOT want WordPress to be calculating offsets on those times. The original purpose of using the date_i18n, is for translating into other languages where the time might be displayed slightly differently, and because that was the “correct” way to do things… preparing all the output properly for translation. Also, it was a way to make sure the times were displayed the same way you have it set up in the General settings for your site.

    You should check with your hosting company to see what your server time is set to, and if it’s somehow off, that could be messing up WordPress. Because, if you set a time zone in WordPress for your site (which you should), it is still getting the current date/time from your server and then calculating an offset based on what timezone you set your WP site to.

    One quick check would be to create a new post in WordPress, publish it (set to private if you like), and then look at the date/time that WordPress says the post was published, and see if that matches the date/time you actually posted it. If not, then something is off with either your server’s time, or something else in your settings somewhere.

    As mentioned in my previous reply, things are still working correctly here on my development machine using the same function I have always used. WordPress has not deprecated the date_i18n function, but the new code in that function does call the new wp_date function, depending on the way parameters are passed in. The way my plugin passes in parameters, it appears that the date_i18n function tries to reverse calculate the offset to remove from the timestamp first (because originally the function is assuming any offset has already been added to the timestamp being passed in) and then passes that to the new wp_date function (which, based on my testing last night actually DOES calculate an offset to add/subtract from the timestamp). So, it takes away the assumed offset in the old function, and then adds it back in with the new function, which is really a crap way of doing things.

    If this becomes an issue with several sites, and ends up not being a result of incorrect server times, I may need to completely bypass those crappy WordPress functions, and modify the time display directly myself based on the site’s time display settings, and using PHP date functions to format them instead. Time is displayed in so many places in my plugin, that it’s a bit of a chore to rewrite them all, and create my own function to run them all through instead of the WordPress functions… I hate rewriting code that already exists in the core of WordPress, but, that may be the only choice if this becomes a big issue.

    So far, you’re the only one who has reported this. But, WordPress 5.3 also just came out, so probably not too many people have updated yet. And, according to their code comments, WordPress just change that core function in version 5.3.

    Thread Starter the_webscaper

    (@the_webscaper)

    Thank you for the detailed explanation 🙂
    At this point only two of my client sites are experiencing the issue. Trying to determine common denominator as far as plugins on these two that do not exist on the other sites. They are all Genesis theme. All hosted by SiteGround (separate individual accounts, not the same server). All are running WP 5.3.

    As for server time – I checked it from the Settings > General page on each site, and all of them are showing the correct time. I assume this is coming from the server, anyway?
    As shown here: http://prntscr.com/q2x76w
    They’re all matching my own local time.

    I appreciate the thought you’ve put into this. I realize this isn’t a problem with your plugin specifically. I just really am at a loss, and of course this client needs to send out the info for the sign up sheet *today.* 🙂 🙂

    I’m going to try deactivating all common plugins and see if magically that fixes it and figure out what conflict is going on here!

    Plugin Author DBAR Productions

    (@dbar-productions)

    Maybe try changing your time zone from “New York” to the UTC offset option?

    Also, quick search found this, which may be helpful?? (show your hosting company, maybe??) – could still be something in your php.ini settings that are wrong??

    https://wordpress.stackexchange.com/questions/301392/wrong-utc-and-local-time-only-on-wordpress

    I’ll be out for a while, and then have some work to do for a paying client, but let me know if you figure anything out.

    Plugin Author DBAR Productions

    (@dbar-productions)

    Also, I note that in your screen shot, the difference between universal time and your local time is the 5 hour offset that you are getting when those times are displayed. This is as confusing to me as it is to you, and, until this happened to you, I was not even aware that the date/time formatting functions for WordPress would even try to offset a time you passed in to them (I believe those time display functions were there in the original version of the plugin, from another developer, that I took over to port to my own custom version about 8 years ago, so I never looked into it that closely, and it’s never caused any issues, until now). Definitely something to do with your particular settings in conjunction with their update to those functions in 5.3. Maybe it will affect others as well, and WordPress will release a patch to fix it?

    Thread Starter the_webscaper

    (@the_webscaper)

    I just found this thread — I assume your plugin is not using date_default_timezone_set which seems to be the common issue for other plugins experiencing this problem, see here:

    https://wordpress.org/support/topic/timezone-is-off-displaying-utc-on-all-events/#post-12138155

    So I think finding what plugin(s) are using this and deactivating would fix (and of course then cause me other issues since we need these plugins… ). I’m checking that next.

    This is insanely frustrating. A patch to 5.3 would be great but I wonder if they would, if it’s “bad” plugins being the problem not the change made by WP? </rhetorical>

    Thread Starter the_webscaper

    (@the_webscaper)

    Found the culprit on one of the sites! Plugin called Ultimate Auction Pro which I have had massive issues with before………..
    So at least ONE of the sites is fixed now.
    That plugin isn’t on the other, so I need to go one by one on that site to find the next errant plugin.

    Thank you so much for your thoughtful help even though this wasn’t your plugin’s fault!

    Plugin Author DBAR Productions

    (@dbar-productions)

    No, my plugin is not messing around with time zones, or timezone settings, in any way at all. I’m assuming that the time you enter for a task is the exact time you want shown, and I’m simply using those WP functions to format and “translate” the display of the time, as needed.

    Glad you were able to find that thread and start to track down the problem plugins.

    I’m going to mark this as resolved, since it’s not any issue with my plugin, but I’ll keep in mind as a possible future update to rewrite the way I display times to completely bypass those WP functions, so this type of thing doesn’t become an issue on other sites.

    I had the same issue with another plugin. 5 hours out of sync. This post gave me the info to fix it. Thanks, Guys.

    Seb

    (@ssamyn)

    Hi,

    I have the same issue but I cannot find which plugin which causes the issue yet.

    I reverted back to WP 5.2.4 in the meantime.

    Plugin Author DBAR Productions

    (@dbar-productions)

    I’m getting close to releasing the next major version, 3.0, with a LOT of changes and improvements. I considered switching to just using the PHP date function to format dates and times based on the way the admin has it set in the WordPress general options.

    However, if I do it that way, then you lose the ability to translate dates and times into other languages/locales, which is the main reason I use the WP date_i18n function. I do have translations for my plugin in several different languages, as people in several other countries use it. So, I would hate to lose any translation abilities on date/time simply because of some plugins, or themes, using a function that, according to WP, they should not be using any more to set a default time zone (that is handled in WP general settings, and should not be overridden by other plugins/themes).

    If this becomes a big issue after everyone gets around to updating to WP 5.3+, then the only thing I would feel comfortable doing is to create my own small date/time display function to run all those through, and then create an option for admin to decide if I use the date_i18n function (if translation might be necessary), or to use the PHP date/time function to generate the displayed times and dates (if you don’t need translations from whatever you PHP locale is set to).

    Thread Starter the_webscaper

    (@the_webscaper)

    Hi Stephen,

    Revisiting this issue, because it’s happening again on my client website: https://neweaglepto.org. The last time we had the time display issue, a plugin Ultimate Auction Pro was the culprit. They do a major auction fundraiser once a year; last time this happened, there was no auction so we disabled the plugin and Sign Up Sheets times were fixed.

    Now it’s auction time again. The auction plugin has since been entirely rewritten and now integrates with Woo Commerce, and is now called Ultimate Woo Auction Pro. Our hope was the new plugin wouldn’t incorporate whatever code was the issue last time. Unfortunately, as soon as we installed the plugin, the times for our Sign Up Sheets went wonky again.

    I DO understand your explanation that this isn’t a problem with Sign Up Sheets. I DID open a ticket with the developer of the auction software. I bring this to your attention today because we are between a rock and a hard place. My client needs both plugins.

    I did just install the 3.0 update of your plugin, hoping that maybe that contained a solution to the issue – but, times are still incorrect.

    I can wait to hear back from the auction plugin developer – but wanted you to know this is still a problem rearing its head, and if that developer can’t or won’t help, I am looking for any advice I can get here. We really need both plugins…

Viewing 15 replies - 1 through 15 (of 20 total)
  • The topic ‘All times suddenly displaying GMT time?’ is closed to new replies.