[y2ksw]

Originally Posted by Bulent Tekcan

I tested now here is the result

mysql> SELECT NOW(), UTC_TIMESTAMP();
+---------------------+---------------------+
| NOW() | UTC_TIMESTAMP() |
+---------------------+---------------------+
| 2016-09-30 17:12:12 | 2016-09-30 14:12:12 |
+---------------------+---------------------+
1 row in set (0.00 sec)


It is not 10 hour different

As for you question (before you edited this one), the server cron jobs usually execute at UTC, but it depends also on how the time is stored in RTC. On my backup server, time in RTC is stored in local time, and thus runs at local time. The servers where I have the hosting running, store the RTC time in UTC, and run at UTC, while the "apache" user runs in Europe/Rome timezone and thus, vbulletin cron runs at that time. This timezone is also default for the mysql users, but my vary if the system administrator wishes.

This classic example makes clear that things can become pretty complex and explains also why vbulletin stores the current time in the constant TIMENOW, relative to the "apache" user. This variable may be then adjusted to specific needs, but this plugin does nothing to it, because it cannot make a choice.

So eventually I could add a parameter in the settings which allows you to change this offset manually, but then there will be quite some user having problems with their timing at another level, which is impossible to guess.

As long as there is no such parameter, there is no need for me to solve server side issues. If there was, I would have every day 10 questions how to make timing work properly, which I can't answer, because every server setting is different.

Taking all possible variables, there are 1*2*3*4=24 legit settings (server, mysql, apache, vbulletin) which would directly influence the behavior of any given setting at one place or another.

I hope I have answered your question and the final, short reply is: "There will be no option to set the offset manually"