[FEATURE]添加选项，将一天从零点开始的前N个小时访问数据视为上一天的。

[queziaa]

今年晚上熬夜的访问不计入明天的统计

[sheepzh]

尝试了下，这个功能似乎看起来很简单，但是实现时需要关注的细节特别多，而且极易产生破坏性的 bug，导致基础功能不可用。主要需要解决的问题有以下几方面：

首先是各个页面查询数据时的的入参问题。

由于 UI 给用户的感知的是真实世界的时间，所以查询时间和统计时间是有偏差的，这时有两种处理方案。

• 其一，系统允许这种偏差的存在并做出适配，比如用户将每天的开始时间设置为 08:00，然后在 2024/01/24 02:00 打开 popup 页面时，理应展示 2024/01/23 （今天）的数据。这种方案几乎涉及所有页面代码的改动，所以很容易遗漏而产生 bug，同时，由于所有的数据查询页面都有默认的时间筛选参数，这种方案也会增大用户查阅数据过程中的理解成本——他访问任何页面时，都需要时刻记得自己将每天的开始时间设置成了 08:00。
• 另外一种方案就是只在写入数据时处理时间偏移，查询时按真实时间查询，如此展示的数据就会有一定延时。还是就上面的例子，用户在 2024/01/24 02:00 时，应该查询 2024/01/24 （今天）的数据，但是展示的数据为空，因为对记录时间线而言，当前仍然是 2024/01/23。该方案的代码改动量较小，但是会导致软件各个功能模块的不协调，同样会增加用户的理解成本。

另一个很大的问题是数据的多端同步。现在所有的数据都是按日期作为 key 存储的，多端数据合并时不能处理各端的时间偏差问题。

用户在变更选项值也会有一个目前无法解决的小问题，比如用户在 2024/01/24 06:00 将选项从 00:00 变更为 08:00 就会导致记录时间线上的 2024/01/23 这一天变成 24+2 个小时，当天的浏览时长就有可能超过 24 小时。一段时间后，用户再回查这段数据时，很容易把它看做 bug。当然系统也可以通过引入额外的数据概念，将这段时间内的记录特别标注出来。但是这个新引入的数据就会变得很不优雅，因为它太客制化了。

综上。很抱歉，目前我放弃了实现该功能。

如果后续产品架构有了新的变化，足以支持该功能的落地之后，我会再次考虑。我也会尽量控制之后的产品演进往这方面靠拢。