Hi Quidby,
That’s very odd. And what about on other pages, does it appear correctly? Few diagnostic questions…
- Does viewing other events cause the associated entry in the widget to appear incorrectly?
- Are you using custom templates for either the event list widget or single event page?
- If you change the timezone does the incorrect date change appropriately?.
On any other pages other than the Event single, the Event list widget displays the correct times.
Yes, the events other than the one being viewed show correctly. Oddly, for an event marked recurring which appears in the Widget Event List more than once, only the first entry shows the wrong start time.
Yes, I’m using custom templates for both the single and the widget. It’s certainly possible I’ve introduced some error, but I don’t see anything that would cause such an odd bug.
Yes, if I change the timezone, the incorrect time changes to match.
The fact that the bug only happens on a page with two calls to the event loop seems telling.
Yes, if I change the timezone, the incorrect time changes to match
Ok, so almost certainly related to the timezone.
Yes, I’m using custom templates for both the single and the widget
I ask is because I can’t replicate it, simply trying to rule out possibilities. If you don’t mind debugging a bit, if you can specify the format in your call to eo_get_the_start() to use the format DATETIMEOBJ (as a constant, not string), and print_r that – this will tell us what timezone the date is in (It should be a city-based time-zone thats +/-7 UTC depending on your settings).
You might want trace the date back to the database via eo_get_the_start() which calls eo_get_the_occurrences_of().
The incorrect time does in fact show a timezone of ‘UTC’, as opposed to the correct ‘America/Vancouver.’ The times are all correct in the eo_events table in the database.
As an aside, thanks so much for the prompt responses. I’m really impressed with your support for the plugin.
So there’s a very short gap between the database and printing the date…
eo_get_the_start() (source) simply uses eo_get_the_occurrences_of() to retrieve all of the dates for an event, and then picks out the one you’re after. The latter deals with the database.
In short it seems odd the problem would be in eo_get_the_start() – but the fact that only one occurrence is affected when the event recurs suggests that it should be.
How are you using the function eo_get_the_start()? If you’re passing it the occurrence ID you’ll need to pass it as the 4th argument, with the third set to ‘null’.
Seems likely its to do with a repeat call to eo_get_the_start() (or the underlying eo_get_the_occurrences_of()). Nothing in the source jumps out as a potential cause with the exception of the cache. (See source). There were problems with php < 5.3, but you could try setting $occurrences to false.
You might also want to check that eo_get_blog_timezone() is returning the correct timezone.
No worries, and thank you :).
Ok. Killing the cache in the eo_get_the_occurrences_of() function fixes the issue. I guess you would know better than I why that would result in the problem I saw. Perhaps my version of PHP is still not correctly caching the DateTime objects. For the record, the PHP version of my XAMPP server is 5.3.8.
Will have to check, but I guess its loosing the timezone in the cache. It might be best to cache it as a string and re-initialise the DateTime object.
Odd that this problem doesn’t occur more often. Do you have any sort of cache plug-in installed?
Sorry for disappearing on you, Stephen. Whatever the problem was is now gone after the plugin was updated this week, so thank you for that fix. For the record, I did not have any caching plugins installed at the time. I am going to install W3, though, so fingers crossed that it doesn’t cause any new grief.
Thanks again for the great response.
