When a timezone is specified w/ a string like
'today', the result of
Date::factory() is incorrect since it will get today in UTC and then apply the timezone. Since today in UTC removes the hour/minutes, the adjusted time can move into a different, incorrect day. (eg, timezone is UTC-5, time is 1 am Dec 3, UTC today is Dec 3 midnight, applying timezone yields Dec 2 19:00). Fixed by calculating timezone & date together using
I'm not sure if this will have a performance penalty, hopefully not.
It looks good so far.
Note: need to add some tests & I think yesterdaySameTime needs a change.
No, I'm afraid it isn't quite right. Now - December 4, 22:00 EST, which notably is December 5 UTC - I'm getting all zeroes in the "Visits Overview" box. I think that box (which worked correctly before the patch) may now be getting the time zone correction applied twice or something of the kind. All the reports under headings like "Behaviour" and "Acquisition" are saying "There is no data for this report."
getTimestamp()is meant to apply the timezone, but
Date::factory()was applying the timestamp again.
getTimestamp()didn't seem to work for me.
adjustForTimezoneworks, however, so switched to using that.
todaycould only be computed by first finding 'today' in the requested timezone using
nowin the requested timezone, then undoing that and getting that time in UTC, then using that in a
Dateinstance so eventually the timezone application in
getTimestamp()would convert it to the right time.
Think this change should do the trick. EDIT: or maybe not since the build is failing.
It's hard to test and reproduce these things (and probably lots of different combinations). I reckon if user confirms it works it should be fine to merge and ideally we release a new beta soon.
Will try and fix the build tomorrow, don't want anyone to use the code until every test passes.
@tsteur fixed the build, looks like the timezone calculation was actually reversed before (UTC+1 calculated as UTC-1).
I don't think this latest patch works at all. With a few days of testing it's giving me weird results, including multiple consecutive days that show the same summary statistics, and stats not restarting at zero at local midnight. I'm finding it hard to characterize exactly what's wrong - it's not as simple as just showing yesterday's stats in place of today, or resetting things at UTC midnight instead of local midnight - and it seems to differ between different Web sites that collect their stats on the same Matomo server. My best guess is that there's something cache-related being screwed up, but resetting the cache doesn't seem to fix it. I just hope that the problem is only in display, so that when there's a version that works, the data collected during these few days won't be trash.
@mskala That's a bit harder to diagnose from this end. Could you elaborate on "including multiple consecutive days that show the same summary statistics, and stats not restarting at zero at local midnight"? Screenshots might help if that's possible.
@mskala Actually, I think you're right, this change isn't right, I would undo it. If the data doesn't look right, you may have to re-archive it, but I think the underlying log data should be fine.
I'll let you know explicitly when I have something that's worth testing.
See screenshot.. the Visits Over Time graph shows exactly 37 visits with bounce rate of 77% for both December 8 and 9, which seems like a surprising coincidence. At one point today, shortly after midnight this morning, it was also showing that same number of visits and bounce rate for December 10 and in the Visits Overview box, with new visits not resulting in changes to the Visits Overview box. Some, not all, of the other Web sites on this Matomo installation were showing similar behaviour (identical stats for Dec 8 and 9). However, I haven't been able to reproduce the three-days-in-a-row behaviour when trying it just now. I've been through several replacements of Date.php since.
@mskala this PR is ready for another test, make sure to change Date.php & Range.php. These changes shouldn't affect any other part of matomo, so no side effects, but I noticed much of how Date.php deals w/ timezones is just off, so there may be other issues like this elsewhere.
Okay, I think this one works. I've run it for a couple of days, testing stuff like before and after midnight local and before and after midnight UTC, and I haven't caught it in any incorrect behaviour. Looks good!