Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When a custom date range is requested, the timezone of the requested website may be ignored #5356

mgazdzik opened this issue Jun 17, 2014 · 3 comments


Copy link

@mgazdzik mgazdzik commented Jun 17, 2014

There is bug in Archive::build() method.


In (1) timezone is being only passed to Period factory (2) when it's not range (so day,week,month,year, single date). If we take date range (startDate,endDate), period = range, or use lastN/previousN the timezone is not being passed to factory.
This causes reporting to show next day relatively to site timezone, even though current day hasn't ended.
To fix that - simply we need to pass timezone string taken from Site object, to Period/Factory where new Range() is being created.

Copy link

@mattab mattab commented Jun 18, 2014

When reporting a bug, it would be super helpful if you also report the steps you used to reproduce this issue in an isolated way.

Steps to reproduce are important to help trouble shoot the issue, but also we need steps to know how to write a test case (since test case usually closely matches steps to reproduce).

I tried to reproduce the issue as follows:

  • Create website with timezone New York
  • In NY timezone, the day is still June 17th. It is June 18th in UTC.
  • I track a visit in that website in June 18th UTC / June 17th in NYC timezone
  • requesting: index.php?module=API&method=VisitsSummary.get&idSite=1&period=day&date=2014-06-17,today&format=xml
    I get this response:
<?xml version="1.0" encoding="utf-8" ?>
    <result date="2014-06-16" />
    <result date="2014-06-17">
    <result date="2014-06-18" />

  • there's an extra entry for "2014-06-16" (which is different bug).
  • the data looks correct.... maybe I missed something?
  • how can we reproduce the issue in isolated test case?
Copy link
Contributor Author

@mgazdzik mgazdzik commented Jun 21, 2014

I've re-thinked this issue and I think I've found way to reproduce issue. Here are steps to this:

  • create site with timezone different than UTC
  • run Archive::build() with this idsite, period=day and date=2014-06-19,2014-06-20
  • then pull out generated periods with $archive->getParams()->getPeriods()
  • var_dump those periods (timezone is protected attribute, so there's no nice way to see what's there)
  • you should see that computed periods have UTC timezone set, while it should match timezone of site.

For convienience you can use this quick plugin with API method to peek into timezones:

As for reproducing in isolated test case - I think steps should be quite the same.

  • build archive for site with different timezone than UTC,
  • try to pull out timezone for generated subperiods,
  • check if they match with site's timezone.

This test should cover all cases, in which Period::factory will be using Range class, so it would be period=range, lastX, previousX, or date spans like 2014-06-19,2014-06-20 (possibly there will be more cases ?).

Just to clarfy - actual problem is with time-shift between proper midnights in different timezones, can cause for ex. situation when it's 2014-06-20 before midnight of New York time (while it's after midnight in UTC) , user querying for date = 2014-06-18,today will recieve data including 2014-05-20 .. which hasn't actually started in timezone of site.

Hope this makes this issue reproduceable and easier to solve.
Please let me know if I can provide any more help with this ?

Copy link

@mattab mattab commented Jul 1, 2014

In de6104d: Fixes #5356 Applying change suggested in pull request #320
(the only change was to set default timezone to UTC)

@mgazdzik mgazdzik added this to the 2.4.0 - Piwik 2.4.0 milestone Jul 8, 2014
@mgazdzik mgazdzik added T: Bug labels Jul 8, 2014
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.