Base all cron jobs off admin settable time and not GMT

bzcomputers

bzcomputers

Well-known member
Currently cron jobs, if set for a certain hour of the day to run like the Daily Statistics cron, run based off of GMT time. This makes it more of a "24hr statistics" than a "daily statistics" unless you live in the GMT timezone and then you get lucky.

Although this isn't the end of the world, it would be more useful and more accurate to actually have daily statistics.

It would be nice if XenForo based cron jobs off of admin settable options. This would require an option to set your timezone and whether you observe DST and then base cron jobs off that. Then those of us that don't live in the GMT timezone will still have accurate daily statistics.

Currently in order to run accurate hour based cron jobs requires you to manually adjust the time by your time zone offset and then going back in and re-adjusting them after each XenForo upgrade.
 
Upvote 30
I could be wrong, but wouldn't the crons be based off of the guest timezone you set in the AdminCP? 🤔
If that's not the case, then it's likely based off of the server timezone.

Or I could be entirely wrong and it is hardcoded to GMT, in which case ignore me and carry on 😅
 
DragonByte Tech said:
I could be wrong, but wouldn't the crons be based off of the guest timezone you set in the AdminCP? 🤔
If that's not the case, then it's likely based off of the server timezone.

Or I could be entirely wrong and it is hardcoded to GMT, in which case ignore me and carry on 😅
Click to expand...

Any cron I have set for running at a specific hour, like "Daily Statistics" at midnight currently runs exactly 5 hours earlier than expected. Which I don't think coincidentally is also my current timezone offset (from GMT to CDT).

When I was confused with my findings, my search came up with a few other threads dating back to 2012 with people referencing the same and staff confirming that this is how it has always been:
xenforo.com

As designed - Cron "next run" has wrong time

I've reproduced this on two different computers. On one of them, I can confirm that the system, php, xenforo public and my xenforo user timezones are all the same (GMT+11). If you create a cron event that uses the default time settings (midnight every day), or look at any default cron event...
xenforo.com xenforo.com
xenforo.com

XF 1.5 - How can I find out when Xenforo Cron runs?

This is probably really stupid on my part. I looked in crontab -e and don't see any entries that are associated with XenForo. How can I see what the cron tasks are and when they run?
xenforo.com xenforo.com
xenforo.com

XF 1.3 - Cron Schedule

I have a job setup to run @ 00:00 Daily, but it doesn't appear to be running at midnight. Why would it run at 7PM? When I adjust this to run at 1AM it says it will run next at 8pm... Server is setup for GMT-6 as is my user profile.
xenforo.com xenforo.com

Seems like an easy change to implement. Not sure why it has been this way for so long. I don't think most people know about it (and I'm sure many don't care too).
 
I think many recognize that as a feature of cron jobs and simply offset the run times to correspond top the local time.

I wouldn't object if they changed it but I also don't care if they leave it as it is. Just not a major issue for me.
 
djbaxter said:
I think many recognize that as a feature of cron jobs and simply offset the run times to correspond top the local time.

I wouldn't object if they changed it but I also don't care if they leave it as it is. Just not a major issue for me.
Click to expand...

As far as I know, that means each time you update the software you'll need to redo the cron time settings. For me and my typical IT induced OCD this required me to post a suggestion on a permanent fix.

I'm sure there are a few other OCD admins out there that'll give me a like.
 
As @ozzy47 already implied:
You can't modify XF cronjobs (unless you've got development mode enablend) execution time.
You you can create you own Add-on ad add entries with the same callbacks and disable the existing ones; they won't ge re-enabled upon ugrades (unless you disabled them in development mode; don't do that!)
 
@ozzy47 and @Kirby - Thanks for the further details on XenForo cron job behavior.

I still think the simplest solution is to just give admins a timezone setting option. I like my XenForo to be like my Ronco Rotisserie - set it and forget it.

set-it-forget-it.webp

God knows how many sites and platforms some of us deal with on just a daily basis. I know the less I have to remember the better. Give me an initial setting when I'm installing and I'm a happy admin.

...still holding out for my first like above
 
Just wanted to add my voice to this, its super frustrating if you live in a timezone way outside of GMT. If you install an addon that has a cron its set to something that can't be changed. I have to go through and disable all of the default crons and create new ones and then also I have to guess at the time.

My server time is set to mky timezone, my settings and guest settings are set to my timezone, but this one vital corner of the site is rogue. Most of my crons run critical procedures likely cause significant load to the website. They shouldn't be run when the site is busy any active.

For instance the daily cleanup task can cause some headaches as it is set to run at 1PM in my timezone instead of the more appropriate time of 3am
 
The real pain is remembering to change it an hour every daylight savings time and after when you have crons that need to run at a specific time. The offset is a not problem, but the offset gets messed up since UTC does not honor the hour difference. So it is not set-it-and-forget-it, it is... set-phone-reminder twice a year! Annoying.
 
Last edited:
Cannot agree more with the need for this to be fixed! I have read the threads for the "justification" on this... but seriously... "consistency"?? That's precisely what the decision to base all cron jobs (which you can't change the time for, unless in dev mode) on UTC is not.
  • It makes the UI inconsistent (i.e. next run is in your configured TZ, but config is in UTC).
  • It makes statistics reporting inconsistent (I wasted a bunch of time trying to figure out why my stats were a day behind, only to find it was because the job processing it 7 hours off of my expectation).
  • It's inconsistent with standard convention (default of cron jobs runs on server time, typically)

This should be user configurable. I'm fine with it defaulting to a fixed UTC for backwards compatibility (though a proper default should always have been server time). But someone made a good argument for configurable separate from server time, in that they manage servers in another TZ regularly and would like things to be based on their time and not the server's time.

Another argument for this... why would jobs bearing load on a system (not that I've noticed, but still a key point) be universal. Everyone's systems will have different peak times, typically based on the TZ of the server/audience. As a former Linux/Unix admin, you have many jobs that you want to be at low peak times. And while they are hard coded to run at typical "off hours" for UTC, they run on my server during the evening bump in traffic. And the statistics... midnight makes total sense... if within the time zone of the system or admin or user-base cycle.

So, definitely upvoting this request. Honestly, I'm still unclear why all the default crons are hard coded to begin with. Two simple solutions... 1. Let people set the TZ for cron processing... 2. Make all default cron jobs editable. The former would be the least confusing to people.

Just my $0.02.
 
Last edited:
Has this ever been fixed?

I don't ever remember this being an issue but all my crons are running at 7pm EST when they are set at 12am.
 
Back
Top Bottom