和我之前的许多人一样，我一直试图通过连续 100 天访问我的论坛来获得“爱好者”徽章。现在我几乎就要成功了。我想我只连续错过了一两天，这让我对报告的访问次数产生了怀疑，但真正异常的是统计数字对不上。
在“用户”报告的季度统计中，我的记录是 92 天，这应该是整个季度的数据。
在管理员视图的“3 级要求”中，我的访问记录显示为 92/100 天，即 92%，远超 50%。
根据这两个事实，我们必须得出结论：在过去，从第 100 天到第 93 天，我至少离开了 8 天。
然而：在“用户”视图中，如果我查看年度访问统计，我的得分是 360 天——这意味着一年中最多只离开了 5 天（不考虑闰日）。
所以，其中一个统计数据不太准确……或者是我自己弄错了。
（当然，这不算严重的问题，但如果确实存在漏洞，它可能会影响其他方面。）
我已经安装了数据探索器插件，并运行了 如何查看我连续访问论坛的天数？ 中的查询，结果显示我的连续访问天数为 99 天。如果这是正确的，那么管理员视图中报告的 100 天内的访问天数一定有误——如上所述，tl3_requirements 显示为 92/100。
| 用户名 | 起始范围 | 结束范围 | 天数 |
|---|---|---|---|
| EdS | 2019-10-07 | 2020-01-13 | 99 |
| EdS | 2019-09-29 | 2019-10-05 | 7 |
| EdS | 2019-07-28 | 2019-09-27 | 62 |
更新：我获得了“爱好者”徽章，因此这种计算出席率的方式已达到 100。但等级 3 要求的计算显示为 93/100。而数据探索器中连续出席天数的计算则显示为 101 天。
这中间肯定有什么蹊跷。
这很可能是时区误解。服务器时间始终使用 UTC，因此计算规则是：您必须在该日的 00:01 至 23:59（UTC 时间）之间访问，才算作有效。
这些数字以及许多其他数字在 2014/15 年期间曾在这里和其他 Discourse 实例中引发大量查询。当时有很多新用户想要获取徽章，而我们当时对 Discourse 并不太信任。其中一些差异确实是 bug，因此大多数计算结果已经得到了相当充分的确认。
我自己也检查过一些。我记得曾获取我的数据并统计访问 Discourse 的 UTC 天数。我有来自网络监控软件的第三方统计数据，可以用来双重验证 Discourse 的统计结果。如果能发现一些重大异常就好了，但 Discourse 的统计对我的数据来说是准确的。
这并不意味着现在没有问题，只是看起来不太可能。
顺便提一下，我仍然没有获得该徽章，因为当我处于地球上与 UTC 时区相距最远的地方时，很难按照 UTC 来工作。
我使用徽章只是为了激励签到。令人怀疑的不是徽章本身，而是计数。至少有二到三个系统在统计出勤天数，但它们的数据并不一致。
时区问题确实可能导致某人认为自己已在 N 天签到，但系统却未显示为 N 天签到——不过这里的情况并非如此。
总结一下，我们在以下场景中看到出勤天数的统计：
补充几点想法……
我唯一能想到的可能对此行为产生实质性影响的场景是 L3 降级。如果 L3 出勤计数“有误”，某人可能因未达到 50% 的出勤目标而被降级，而实际上他们并未错过该目标。
我有一位成员，根据数据浏览器显示其出勤率为 100%——连续 290 天——但在 L3 要求页面上却显示为 100 天中的 97 天。
我知道这很老了，但出于好奇，您是否解决了这个问题/它是否神奇地解决了？
我没有弄清楚，我很确定它不会自行解决，所以我很有信心那里仍然有问题。我没有阅读任何代码，也没有深入研究。正如我所说，对于大多数目的来说，这只是偶然的兴趣，只会推迟一周左右的徽章或晋升。但关于 L3 降级的评论仍然有效。
如果我负责一个无法计数的代码库，我想这会让我烦恼！它甚至可能让我有兴趣去研究它，但并非每个人都是这样。
我所做的查询很容易在其他论坛上完成——我想可能不是在沙盒上，因为它不是长期的。