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" ?>
<results>
    <result date="2014-06-16" />
    <result date="2014-06-17">
        <nb_uniq_visitors>1</nb_uniq_visitors>
        <nb_visits>1</nb_visits>
        <nb_actions>1</nb_actions>
        <nb_visits_converted>0</nb_visits_converted>
        <bounce_count>1</bounce_count>
        <sum_visit_length>0</sum_visit_length>
        <max_actions>1</max_actions>
        <bounce_rate>100%</bounce_rate>
        <nb_actions_per_visit>1</nb_actions_per_visit>
        <avg_time_on_site>0</avg_time_on_site>
    </result>
    <result date="2014-06-18" />
</results>

• 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?

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:
https://github.com/mgazdzik/PeriodsDebug

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 ?

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