Fixed Birthdays wrong in one area, right in another

[beerForo]

The birthdays in the Birthday widget are correct. But on the member page under Today's Birthdays, they display hours early (the next day). Last night around 11PM I noticed this (but probably happened earlier). So each place had different birthdays listed. I would imagine the widget is reading my user time, but the member page is reading UTC? I figured it's a bug not a setting since they were out of sync.

 

[Chris D]

The code for both of these is essentially identical, aside from the fact that the birthday member stat can be cached for a period of time (an hour, by default).

But if caching was involved, unless you've got a particularly high cache timeout (over a day) I wouldn't expect a discrepancy to happen until after midnight. At that point the member stat may be showing yesterday's birthdays briefly whilst the widget would be showing today's.

So, outside of that, I can't imagine what the problem would be. As I say, the code is identical, so the widget and the member stat would be working towards the same rules in terms of timezone.

As for troubleshooting I'm not certain where to start but when/if it happens again, disabling listeners in src/config.php ($config['enableListeners'] = false;) is a good start to see if anything changes.

 

[beerForo]

It happens every day. Not sure when it happens I'll look for the time tonight and try that and post back.

 

[GW2]

I have noticed this birthday situation also. I have assumed that it occurs because of differences between the time zone in which the server is located, the time zone in which an user is located, and time when the related cron job runs.

 

[beerForo]

Do you notice that they are different in each area at one point?

 

[beerForo]

EARLY (on members page) is the issue.

 

[Chris D]

It might have just dawned on me why this is happening and it's another scenario which involves the member stat caching.

The member stat caching is run hourly by cron entry and we cannot guarantee which user the cron is executed as. This is a time sensitive operation so we probably just shouldn't allow the results of that one to be cached as the results may be different for each user.

You can't disable the cache time yourself, but there is a way to test this. When you see this issue later, you can create your own member stat, copying all of the same settings - but a different member stat key and disabling the cache. That will probably prove the caching is the issue but I'm going to make that change anyway for the next release.

 

[XF Bug Bot]

Thank you for reporting this issue, it has now been resolved. We are aiming to include any changes that have been made in a future XF release (2.2.7).

Change log:

Disable caching for the birthdays member stat. The results could be different for each user depending on time zone so caching won't be effective.

There may be a delay before changes are rolled out to the XenForo Community.

 

[beerForo]

It might have just dawned on me why this is happening and it's another scenario which involves the member stat caching.

The member stat caching is run hourly by cron entry and we cannot guarantee which user the cron is executed as. This is a time sensitive operation so we probably just shouldn't allow the results of that one to be cached as the results may be different for each user.

You can't disable the cache time yourself, but there is a way to test this. When you see this issue later, you can create your own member stat, copying all of the same settings - but a different member stat key and disabling the cache. That will probably prove the caching is the issue but I'm going to make that change anyway for the next release.

Seems to be fixed thanks!