Open amir20 opened 5 months ago
@amir20 Do you have any data points that are in the future? We calculate the end of the period as your max timestamp currently
I don't think I do. I was curious so started switching between different dates. It is weird that the time range jumps between last day, week, 14 days and 4 weeks. I think if you said is true, then I would expect the ending time to always be consistent.
Here is a video recording to show what I mean. If you see, the end time keeps changing. Even more crazy last 6 hours is June 21st. Which is not true for today on June 26th.
https://github.com/rilldata/rill/assets/260667/3bb22534-0556-4b07-8c1b-39ba317799d3
Let me know if you want me to share my dashboard.
Ah gotcha! Thanks for sharing. Yeah... this is an area we are actively working on right now as the display is slightly confusing. Right now our start ranges are "inclusive" and end ranges "exclusive", so Last 24h would show for example 1 Jan 00:00 - 2 Jan 00:00 which is slightly confusing. Same with the Last X Week as we snap to the end of that week (Monday 00:00).
In your case it also looks like you are running into a double whammy as you also have timezone offset from UTC which makes it even more confusing.
We are currently working on a new time range control in this PR: https://github.com/rilldata/rill/pull/4422 I verified that the 1 day / Last 24h looks correct and as you would expect in that PR, let me also check how Last X Weeks behaves.
@amir20 As @mindspank mentioned, we're making changes to rationalize the labeling of these time ranges.
You are seeing two separate issues:
1) Confusing labeling of time range end points: Formally most software frameworks define time ranges as semi-closed intervals [start, end) where the range is exclusive of the ending time. So a time range of "10-11am" excludes 11:00am. However, for day or above granularity, human conventions are that "June 10-11" to include June 11.
2) Confusing labeling of time ranges with incomplete periods: Rill defines "Last 4 weeks" as a range encompassing four week starts (e.g. three Sundays ago through this coming Sunday). If the current day is Wednesday, we were labeling that range as ending on a future Sunday. (This is similar to defining "Current month" as "June 1-31" even if the current date is June 26).
These coming updates will resolve these UX irregularities you're witnessing.
So my initial intuition on week ending with fixed periods was right.
Isn't it confusing for last 4 weeks
to have time in the future? I can't imagine the user ever wanting a period that doesn't exist.
I have worked on a lot of dashboards and can't recall every having last 4 weeks show data that doesn't exist yet.
Even if the labeling was changed to Current month
I would expect to only show data upto today.
@amir20 We agree with you which is why we're updating the labeling behavior to accord with your expectations. :)
Even if the labeling was changed to
Current month
I would expect to only show data upto today.
For me the above statement would not be correct. For 'Current month' I would expect to see all data for the month of now()
. There are scenarios (like shipping dates that can be in the future using a planning tool) where there is data in the future. I would want to see that data included in 'Current month'.
I think @amir20 would want to see a 'Current month to date' that would show all data of the current month up to the today.
@jaroet Agree, we'd want to support basically "This Month" (2024-07-01 - 2024-07-31) and "This Month so far" (2024-07-01 to now).
We are thinking of supporting that via borrowing the time range syntax from Grafana and extend it to also be able to define the comparison range so that you can get even comparison buckets so that "This Month so far" would compare to "same time range last month"
I saw some small improvements in the UI 🚀
Selecting previous X weeks still seems confusing though. But I have noticed little improvements. For example, today (Aug 10th) still selects up to tomorrow which doesn't exist.
I am not sure if this issue is being worked on actively.
Any update on this? This still seems very broken IMO.
Choosing the last 3 months shouldn't be up to Oct 31st.
Update is that it's been a bit slower then we anticipated.
We did decide to fix the root of the issue and will be introducing a new time syntax completely that will allow you to specify time ranges and have full control over when stop/end would be.
We are currently testing it out and will then port it into all time relevant areas. Judging by our initial plan we are looking at a release by end of October. Low confidence as we might uncover more complexities as we start the nitty gritty implementation but that's our target for now.
Example:
[-1M, now] -1M : d
Last month-to-date by day
Syntax:
Time range syntax
start [, stop] [: grain ] [ @ timestamp|offset_duration ]
^^^
time range partition by grain
That helps! Thanks. This is one of those things I forget about and then get hit when trying to go back in time.
Describe the bug When choosing
last 4 weeks
, the time range is partially in the future. For example, today is June 11th, but last 4 weeks is shown asMay 20 - June 17th
which obviously doesn't exist.To Reproduce Steps to reproduce the behavior:
Last X period
. The bigger the range the more obviousExpected behavior It seems like the logic is using fixed time window instead of last trailing window.
Screenshots
Desktop (please complete the following information):
Additional context I did a quick search and didn't find any other similar issues.