Visit per Server Time wrong after 2.0-b11 update

It appears that updating to 2.0-b11 introduced a new problem with the server time reports.

I have a website configured to be on the New York timezone. The server time report correctly displays visits at the appropriate time for my timezone in most cases, with a very large exception. In cases where it is near the end of the day in NY, but it is the following day UTC, the report shows the visit for the correct hour in the NY timezone, but displays it for that hour on the following day.

For example, at 22:00 December 11th NY Time, which would be 03:00 December 12th UTC, the server time report is showing that the visit occurred at 22:00 on December 12th. It seems the time is being adjusted appropriately, but the date itself is not. I believe that this is equally affecting standard visit report as well, with visits late in the day being recorded as visits for the following day, but I have not confirmed that and must wait another day to confirm.

These problems did not exist in 1.12. I am unable to provide samples to reproduce this on the demo instance because I do not know what its timezone configuration is, and there must be a deviation between the configured timezone for a site and UTC time in order to see this happen.

Thank you for the report! This is very interesting bug. I suspect it has been there for a long time but nobody reported it so clearly. Could you additionnally please post a screenshot? And if you dont mind directly creating the ticket at: copy pasting your very good description here?

Does the “wrong date” issue affect only the “Visitor Log” , and also the “Live real time visits” widget ?

Visitors in real time report in the UI appears unaffected. I cannot test the visitor log issue within the UI because it does not allow me to select dates for tomorrow. In the API however, it appears that every call I make that involves returning a visit count is affected by this. Not only are the server time hourly results showing the data for the correct hour one day in the future, but other reports are returning visit counts for tomorrow (as of 19:00 local time, 00:00 UTC +1 day).

Could you please post a screenshot that could show the problem because I’m sitll not fully understanding?

Do you see by any chance the same problem on the ?


I am getting these results using the API, so there aren’t really any screenshot that I can provide.

I don’t know if this is reproducible on because it requires the websites to be configured with a timezone other than UTC. I dont know what timezone the sample site on is running on, so I wouldn’t know how to test it there.

I don’t know how else to expand on what I’ve already said, but I will try to sum it up again in a different way…

My sites are running in the New York timezone, which is -5 hours from UTC.
At 19:00 New York time, on a Thursday for example, it is 00:00 Friday UTC.
Visits between 19:00 and 23:59 NY time on a Thursday are being tracked/reported as visits between 19:00 and 23:59 Friday.
Simply put, the times of the visits are always correct when looking at the servertime reports, but if it is the next day in UTC time at the time of visit, the visit is being reported as happening the next day, which is still in the future for NY time.
On December 12th all my visits after 19:00 we’re being reported as visits on December 13th, even though it was still the 12th.
The time is always being reported correctly, but if there is a difference in the website timezone’s current day and UTC’s current day, the visit is incorrectly being attributed to the UTC current day.

Thanks for the detailed report. to reproduce the issue I just set the site ‘virtual-drums’ to New_York timezone.

When you can reproduce the issue could you post message with URLs and link to pastebin with relevant API output ?

This would be very helpful and then i’d create a ticket to have it fixed!

That link is a report for visits by the hour, based on server time.
The site has been set up in the New York timezone.
It is currently 20:15 on Sunday the 15th in NY.
The report is for Monday the 16th… it should be empty or all zeros. Instead, you will see a count of visits for 19h and beyond (depending on when you are able to check this link)


This is a report for tomorrow the 16th as well, you can see it is returning a visit count as well (5 visits as of 20:15). You need to view this report before 00:00 Monday NY Time otherwise it wont seem like an error to you. For those reading this in the future, you will need to adjust the dates in the API calls to be one day ahead of current NY time and view these report after 19 to 20h NY time to reproduce the error.

facing the same problem, just wanted to ask if the bug has been resolved.


We are investigating the bug and will fix asap: Timezone bug? Visits being reported on the correct hour · Issue #4380 · matomo-org/matomo · GitHub

I have similar problem, my stats for hour after midnight are always zero. When I run archiving manually, it does not do anything if I run it between 0:00 and 1:00, it just quickly runs through as if there were no visitors.
My website is set to UTC+1. If I set website’s timezone to UTC, everything works fine, however the displayed stats are 1 hour off, of course.
It would be nice if it was fixed ASAP, it’s very annoying.

We think we have found the issue! Can you please apply following change. Open file core/DataAccess/LogAggregator.php
replace at line 149

$this->dateStart = $params->getPeriod()->getDateStart();
        $this->dateEnd = $params->getPeriod()->getDateEnd();


$this->dateStart = $params->getDateStart();
        $this->dateEnd = $params->getDateEnd();

(source = Fixes #4380, make sure site's timezone is applied when selecting log … · matomo-org/matomo@2f3bb08 · GitHub)

Then either delete the piwik_archive_*_2013_12 , or wait up to 24 hours to see if the bug is fixed.

Does it fix it?

Thanks, it worked! I didn’t even have to delete anything, just manually run the archiving.

The fix worked for me as well.

I also manually run the piwik/misc/cron/archive.php?token_auth=API_KEY - but I must warn you - it does take some time (a few minutes for me).

Worked perfectly …thanks !

I’m a little late to the party here, but I have also confirmed that this is now fixed.