1) Go to http://mozmill-release.brasstacks.mozilla.com/#/general/top 2) Change the From Date. Pick 2010-11-01 from the calendar. 3) Observe the report refreshing. EXP: From = 2010-11-01 ACT: From = 2010-10-31 4) Change the To Date. Pick 2010-11-05 from the calendar. 5) Observe the report refreshing. EXP: From = 2010-10-31, To = 2010-11-05 ACT: From = 2010-10-30, To = 2010-11-04 Plainly one aspect is whichever date you change, you get the date one day before it. But it also seems to subtract one from the other date as well.
8 years ago
OS: Mac OS X → All
Hardware: x86 → All
I had filed this issue under the project a while back at Github https://github.com/whimboo/mozmill-dashboard/issues#issue/2. If I recall correctly, Henrik wasn't seeing this whatsoever, albeit it's a definite issue that needs attention.
Hm. Well, I'm fairly sure the bug is that somewhere some routine takes M and actually processes M-1; iow, it's a basic off-by-one error. If whimboo wasn't seeing it, I wonder if it was somehow locale-specific (but...browser locale? weird.) If nothing else, I can demo it for Henrik while he's in the MTV offices.
(In reply to comment #2) > Hm. Well, I'm fairly sure the bug is that somewhere some routine takes M and > actually processes M-1; iow, it's a basic off-by-one error. > > If whimboo wasn't seeing it, I wonder if it was somehow locale-specific > (but...browser locale? weird.) > > If nothing else, I can demo it for Henrik while he's in the MTV offices. Sounds to me like he is the only one who was unable to reproduce it; Aaron, myself, and it seems you are all able to reproduce this issue. I first reported it well over a month ago; it was dismissed because Henrik could not reproduce it. Just another case proving that unreproducible != invalid.
Please file tickets for dashboard issues on Github directly for now. The whole application is still in alpha and needs a lot of new code and fixes. It's better for me to handle that over there. Lets revisit it when it's ready. So far this is a timezone issue. Everyone who has a '-' offset compared to UTC seems to be affected by that. I will close this bug here as invalid.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INVALID
Conversed with whimboo in person, rolling up here. I kinda feel like now that the dashboard is part of our daily flow, it should be tracked on Bugzilla. However, it makes sense to have it separate from the Mozmill Tests project. I raised the idea of maybe having another component to cover QA Automation infrastructure issues (nightly runs, dashboard, lab machines, etc.), and we're going to discuss further next week when people are in town.
Move of Mozmill related project bugs to newly created components. You can filter out those emails by using "Mozmill-Tests-to-MozillaQA" as criteria.
Component: Mozmill Tests → Mozmill Result Dashboard
Product: Testing → Mozilla QA
Reopening now that we have our own component. I hope to be able to fix it for our testday next week.
Assignee: nobody → hskupin
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
QA Contact: mozmill-tests → mozmill-result-dashboard
The problem here is indeed the local timezone. By selecting a date from the picker or by directly entering it into the url, will automatically convert it to local time. Because specifying a date is at 00:00, 8h are subtracted for PDT and you will end up with the former day. That means everyone with a timezone difference <0 is affected. Working on a fix now.
The .format function simply missed a second parameter which tells to format the time in UTC. Fixed with: https://github.com/whimboo/mozmill-dashboard/commit/fb1b2cb7201d78698b4a2f75fdbb61c3f889aa3c
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago → 8 years ago
Resolution: --- → FIXED
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in before you can comment on or make changes to this bug.