Setting time for new day?

[luroc]

Is there a setting for what time to start a new day on that I am overlooking?

Otherwise I would appreciate to have that option.
I mostly care for the daily usage and I am browsing past midnight often enough, so I'd prefer to have everything occurring before, say, 6 am to be counted towards the day before.

[sheepzh]

hi @luroc, thank you for bringing this up. this feature was submitted by someone else 2yrs ago in #249. I'll repeat the original reply here in English.

I gave it a try, and this feature might seem simple on the surface, but implementing it involves a lot of intricate details, and it's very prone to introducing destructive bugs that could break core functionalities. The main issues that need to be addressed are as follows:

First, there’s the problem of input parameters when querying data on different pages.

Since the UI presents time based on the user’s perception of the real world, there’s a discrepancy between query time and statistical time. There are two potential approaches to handle this.

One approach is to allow for this discrepancy and adapt to it. For example, if a user sets the start of the day to 08:00 and opens the popup page at 02:00 on 2024/01/24, the page should display data for 2024/01/23 (today). This approach would require changes to almost all page code, making it easy to miss something and introduce bugs. Additionally, since all data query pages have default time filters, this approach would increase the user’s cognitive load when reviewing data—they’d constantly need to remember that they’ve set the start of the day to 08:00.

The other approach is to handle the time offset only when writing data, while queries are based on real-world time. In this case, the displayed data would have a certain delay. Using the same example, if a user queries data at 02:00 on 2024/01/24, they’d expect to see data for 2024/01/24 (today), but the displayed data would be empty because, from the timeline’s perspective, it’s still 2024/01/23. This approach requires fewer code changes but leads to inconsistencies across different functional modules, which could also increase the user’s cognitive load.

Another major issue is data synchronization across multiple devices. Currently, all data is stored with dates as keys, and when merging data from different devices, it’s impossible to account for time zone discrepancies between devices.

There’s also a minor issue that currently can’t be resolved when users change option values. For instance, if a user changes the start of the day from 00:00 to 08:00 at 06:00 on 2024/01/24, it would cause the timeline for 2024/01/23 to effectively become 24+2 hours long, potentially making the browsing time for that day exceed 24 hours. If the user revisits this data later, they might easily perceive it as a bug. While it’s possible to address this by introducing additional data concepts to flag such periods, this would make the data structure less elegant and overly customized.

In summary, I’m sorry to say that I’ve decided to abandon this feature for now.

If the product architecture evolves in the future to better support this feature, I’ll revisit it. I’ll also do my best to steer future product development in a direction that aligns with this goal.

unfortunately, two years have passed, and all the problems still remain. to complete this function, a systematic overhaul of some underlying logic is still needed. = =