Isn't day-counter automatically reset according to the system time?

This probably means that the php timezone for the server is set to your local time instead of UTC. Can you check your php.ini ?

I updated the time zone in PHP.ini, restarted the server and PHP, but it still hasn't cleared at the correct time. I don't know where the problem lies.

OK, this will need some clarifications so that I can reproduce the problem. Can you detail:

• The result of the command date; date --utc on your server
• The result of the SQL command SELECT * FROM `node_counter`order by `timestamp` desc limit 10;</li>
• The result of the command drush sget system.cron_last on your server
• At which time in your timezone you observe the counters being reset
• If you have any cron module active, like core automated_cron, or contrib like ultimate_cron, Elysia cron, ...
• If you run any cron task from your operating system, like a crontab task, and if so its schedule

Additional info may turn out to be helpful later if the questions above do not allow fixing the problem.

• OS version
• The Drupal version
• The database server version
• The PHP version and SAPI (apache2, fcgi/fpm, cli, ...)
• The Apache configuration, especially vhost file
• A copy of the web/.htaccess file if it has been modified from the distribution (replace sensitive parts before sending)
• The php.ini (take care to replace all passwords/keys before sending it)
• A copy of the /admin/reports/status/php page (replace sensitive parts before sending)
• The statistics.settings.yml file as it is in your config directory

But for now, let's start with the first set.

root@:~# date
Wed 28 Aug 2024 11:05:14 AM CST

root@:~# date --utc
Wed 28 Aug 2024 03:05:00 AM UTC

SELECT * FROM `node_counter`order by `timestamp` desc limit 10;
+------+------------+----------+------------+-----------+------------+-----------+
| nid | totalcount | daycount | timestamp | weekcount | monthcount | yearcount |
+------+------------+----------+------------+-----------+------------+-----------+
| 3326 | 211 | 0 | 1724665745 | 5 | 31 | 228 |
| 1998 | 2887 | 0 | 1724662728 | 1 | 414 | 2888 |
| 7613 | 290 | 0 | 1724662660 | 4 | 44 | 310 |
| 5530 | 328 | 0 | 1724652530 | 1 | 25 | 335 |
| 2062 | 169 | 0 | 1724563551 | 2 | 37 | 190 |
| 9492 | 289 | 0 | 1724563080 | 2 | 40 | 302 |
| 5529 | 3159 | 0 | 1724560171 | 0 | 88 | 1585 |
| 8896 | 139 | 0 | 1724558069 | 0 | 22 | 152 |
| 5930 | 8366 | 0 | 1724557960 | 1 | 273 | 4191 |
| 8621 | 164 | 0 | 1724557443 | 0 | 20 | 168 |
+------+------------+----------+------------+-----------+------------+-----------+
10 rows in set (0.057 sec)

drush sget system.cron_last
I haven't installed Drush yet, but I have set the cron run schedule task to once per hour

OS version: Debian GNU/Linux 11 (bullseye) x86_64(Py3.7.9)
The Drupal version: 10.2.7
The database server version: MariaDB 10.11.6-MariaDB-log - Source distribution
The PHP version and SAPI (apache2, fcgi/fpm, cli, ...): 8.2.19
The Apache configuration, especially vhost file: I use nginx 1.26.0

There are some information that I don't know how to obtain.
Also, I'm not sure exactly when it will be reset, but it's not 00:00. I'm currently observing.

I installed this module: statistics_counter →

I flashed the page at 17:58 and saw it reset. It should have been reset between 17:00-18:00

Not sure I understand your last comment: you said it should have been reset between 17:00-18:00 and it was already reset at 17:58, which is within 17:00 - 18:00 ?

This being said, I notice the data command is returning a non-UTC time, and ISTR that it is generally recommended to have servers use UTC time, adjusting per-user time with the TZ environment variable in their profile. And there is something else: 11:05 CST is equivalent to 17:05 UTC, not 03:03 UTC. See e.g. https://24timezones.com/fr/difference/cst/utc : But I see that Asia/Shanghai is /also/ called CST so there may be a confusion on your system between the generally used US CST and the Asian CST. I would suggest that you set your Linux to use UTC in /etc/timezone instead of a local timezone. Your php.ini already contains the Asia/Shanghai setting so should be alright.

Beyond that, your statistics.settings.yml is incorrect, not enabling views counting, so I think you may have sent the file found in the module instead of the one in your active config. Do you confirm that ? If you haven't installed drush yet, you can check active config values with devel module, at devel/config/count.

When the international time UTC is 00:00, then my server local time is 08:00

However, the reset time of the counter is between 17:00-18:00

/etc/timezone >> I have set this file to UTC, But it didn't solve the problem

I use statistics by Drupal Core, Is it related to this?

Today's reset time is 20:50, The daily reset time seems to be different.

Never mind, it's not very important either.

Thank you for taking the time to answer my question.

Regarding timezone, AFAIK you need to reboot the server for the change to be taken into account.

Regarding statistics, there should not be any technical difference between core statistics in Drupal 10.3/10.4 and contrib Statistics 1.x: the changes only come in 2.x versions and in extension code.

Statistics Counter is not really supported, but seeing how it works should not impact daily resets.

That reset time is strange, though: it looks like it is entirely unrelated to your timezone. Which raises two questions:

• Exactly how do you run cron ? Is it just the "Automated Cron" module in core ? Or something else ?
• If you cannot run Drush commands, run this SQL:
  

  SELECT value FROM key_value WHERE name = 'system.cron_last';/code> : this will always give you the last time Drupal cron was run, which should match your reset time if you only run cron once a day.</li>
    <li>Then <code><code>SELECT value FROM key_value WHERE name = 'statistics.day_timestamp';

  : this will give you the time Statistics daily count was actually reset

The way Statistics resets the daily counts is by running code on each cron, which will check if the current time is more that 24 hours later than the previous reset time. If it is, it will reset all day counts to zero.

This means that if you want real-time-based daily resets, you want to run cron exactly once a day at midnight, not less. If you have very little traffic and you are using Automated cron, e.g. you only have anonymous visitors served from cache, then cron will not trigger on these cached pages, and you may get updates only when someone hits a non-cached page.

So, again, how are you triggering cron ? You can find more info on Automated Cron at https://www.drupal.org/docs/administering-a-drupal-site/cron-automated-t... →

Exactly how do you run cron ? Is it just the "Automated Cron" module in core ? Or something else ?
I only setup this, please see the picture. I didn't add like these:

"30 * * * * web_user /var/www/html/vendor/bin/drupal ..."
Sometimes I manually click on "Run Cron"

.

SELECT value FROM key_value WHERE name = 'system.cron_last';

+---------------+
| value         |
+---------------+
| i:1725251119; |
+---------------+
1 row in set (0.063 sec)

1725251119 = 2024-09-02 12:25:19 Beijing Time

SELECT value FROM key_value WHERE name = 'statistics.day_timestamp';

+---------------+
| value         |
+---------------+
| i:1725167477; |
+---------------+
1 row in set (0.001 sec)

1725167477 = 2024-09-01 13:11:17 Beijing Time

SELECT value FROM key_value WHERE name = 'statistics.day_timestamp';

+---------------+
| value         |
+---------------+
| i:1725167477; |
+---------------+
1 row in set (0.001 sec)

1725167477 = 2024-09-01 13:11:17 Beijing Time

From here, it can be seen that its reset time today is 2024-09-02 13:11:17, then I refreshed the page after 13:12, The day-counter has not been reset. However, when I click to "Run Cron" on 2024-09-02 13:12:55, then refresh the page again, the counter was reset. Then, its next reset time becomes 2024-09-03 13:12:55, Look, it is 13:12:55 not 13:11:17.

Now, I execute the statement again: SELECT value FROM key_value WHERE name = 'statistics.day_timestamp';

+---------------+
| value         |
+---------------+
| i:1725253975; |
+---------------+
1 row in set (0.010 sec)

1725253975 = 2024-09-02 13:12:55 Beijing Time

Conclusion, the day counter is not reset according to the time zone.
It starts calculating the next reset time (24 hours) is: When it reaches the reset time and after "Run Cron", It will reset the current day counter and calculates the next day reset time.

Good conclusion :-)

The problem is that you really should be running cron on a regular schedule: that is one of the expectations of hook_cron. Typical rate is once a day, ideally just after midnight in your timezone, so that reset can be performed at what looks like midnight for your users/admins.

I would advise setting a crontab like 0 0 * * * /path/to/project/vendor/bin/drush core:cron and no longer triggering it manually. Why do you have to run it manually at various points in the day ? This is not typical Drupal practice.

You mean is: close the "Run cron every" to never on page /admin/config/system/cron, Then setup automatic execution of cron tasks by Drush for 0 0 * * * /path/to/project/vendor/bin/drush core:cron

I don't know how to install Drush and configure it.
Is it a global installation or a project-based installation.
After installation, I don't know how to configure it.
When using it, I cannot use like this: drush core:cron, I must use it like this: vendor/bin/drush core:cron

For Drush, if you installed your project using composer, it's just a matter of doing composer require drush/drush. After that, a Drush command will be in your vendor/bin/ directory. From there you can either edit your $PATH variable to include that directory or use it with an explicit path like ./vendor/bin/drush <command>.

Drush does not require any configuration: it works by default. It is usually best not to use a global version, but a per-project version like I just described, because multiple projects on the same machine may need different versions.

Perhaps this is currently the best solution, thank you very much.

Automatically closed - issue fixed for 2 weeks with no activity.