Freecodecamp: 对于许多露营者来说，Streak 仍然不准确

我第一次参与开源贡献，但我很想看看我是否能胜任这项任务。

这仍然是我们收到很多抱怨的问题。

@QuincyLarson我有兴趣帮忙

@sorlovsky 太棒了！ 我们对您的帮助感兴趣！ 看看你是否可以围绕这个编写一些测试来覆盖各种边缘情况。 它似乎在 99.9% 的时间里都有效，但在某些情况下它不起作用，我不太确定为什么。

我对此进行了一些调查，这可能是因为它正在计算当前的挑战连续数，而不是其他活动（项目或算法）。 也可能是如上所述的时区。 我将调查这个问题，看看如果没有其他人解决它，我是否可以进行公关。

如果我在这里遗漏了什么，有人可以告诉我。

const daysBetween = 1.5; 可以更新为 const daysBetween = 2; 因为以下函数中的逻辑总是表示小于 daysBetween 且不小于或等于 daysBetween。 这意味着将从一天的 12:00:00AM 一直到第二天的 11:59:59PM 进行覆盖。 时区逻辑也应该保持不变。

将 daysBetween 更改为 2 意味着两个测试中断，这可以修复，但我必须先了解一下测试的工作原理。

另一种选择是将 daysBetween 设置为 1.99，以便所有测试都通过，但您可能会错过 7 分 12 秒的连续记录。

@donofriov请继续我不知道为什么它不起作用

@donofriov非常感谢您的分析，很https://github.com/freeCodeCamp/freeCodeCamp/issues/7468 （与用户的登录状态有关）

如果您需要任何帮助，请在聊天室中联系我们。

我必须先了解一下测试的工作原理。

测试在
https://github.com/freeCodeCamp/freeCodeCamp/blob/staging/server/utils/user-stats.test.js

嗯，这比平时的结构有点复杂。 如果你需要弄清楚事情，我会在附近。

快乐修复！

@donofriov是的 - 如果你认为这会解决它，那就太好了。 将daysBetween为 2 并更新测试以使其通过。

如果可以，请查看是否可以添加一些额外的测试覆盖范围，以确保这可以解决出现的各种极端情况（有几个与条纹相关的问题）。

感谢您的时间和关注。 这几个月来一直是一个主要问题，并且是许多投诉的来源，因此解决这个问题将是巨大的:)

问题是streak的计算取决于时区。 在一个时区，假设我提交的三个文件是[Aug 5, Aug 6, Aug 7] 。 在另一个时区，这些相同的提交可能在[Aug 5, Aug 5, Aug 6] 。 日历热图同样依赖于时区，并且热图始终使用在浏览器中查看页面的客户端的时区。 所以如果我们想让streaks匹配热图，我们需要在计算中使用客户端的时区。 这基本上就是@LenaBarinova在 2016 年 1 月用 #6333 修复这个问题时所做的。 解决方案是让浏览器在提交挑战时发送用户的时区。 服务器将存储时区并使用它来计算条纹。 但随后在 2017 年 1 月，进行了一次重大重构，改变了提交挑战的方式，并删除了

@Motardo感谢您对此进行调查。 您是否有兴趣并修复此问题以使@LenaBarinova的修复再次工作？

@QuincyLarson再看一眼并睡在上面后，这是我的想法：

计划A
我认为旧的解决方案并不理想。 它要求用户登录才能正确查看自己的个人资料，并且在查看其他时区的其他用户个人资料时仍会显示不一致。

B计划（简单明了，很好的临时修复）
我相信一个更简单、更健壮的解决方案是将任何请求发送给客户端时区以查看任何用户的个人资料，服务器可以根据该时区计算条纹。 那么客户端是否登录或查看了谁的个人资料都无关紧要。 条纹和日历将始终保持同步。

计划 C （复杂的重构，可能的未来路线图）
最好的解决方案可能是根本不计算服务器上的条纹。 服务器应该将原始时间戳发送给客户端，并让客户端决定每个时间戳属于哪一天以及基于本地时区的连续多长时间。 这正是我们对日历热图数据所做的，因此它始终保持一致。

我对 react 和 rxjs 完全陌生，我认为计划 C 超出了我的深度，但我很乐意为计划 B 做一个补丁，我很想听听其他的想法和建议。

@Motardo我绝对同意计划 C 最有意义。

鉴于您发布这篇文章已经 15 天了，您使用 React 和 RXJS 有很大改进吗？ 这可能是一个很好的挑战，可以将您的客户端脚本能力的极限提升到一个新的水平 😉

你好。 #16071

我做了什么：
我首先将连续计算更改为使用 24 hoursBetween 而不是 1.5 daysBetween。 然后，我将上一个时间戳和当前时间戳的 startOf('day') 小时数的差异与 hoursBetween 进行比较，以说明过去 24 小时而不是过去一天完成的工作。 （听起来一样，但可能值得一试）

可能更好的解决方法是，如果您允许用户在设置中设置自己的时区，并且使用该时区计算/设置所有内容。

编辑：有谁知道如何在具有不同条纹集的 localhost 中使用/生成虚拟帐户？

编辑：不要介意所有这些。

试图深入挖掘，发现热图和条纹之间的不一致可能是由热图引起的。 https://github.com/wa0x6e/cal-heatmap/issues/122

@kennethlumalicay我相信我们应该让用户存储他们的时区（使用一些智能默认值），主要是因为我们计划保持前端的服务器端逻辑不可知，因为我们计划使前端越来越静态托管。

@raisedadead我认为必须有一种更简单的方法来处理这个问题，而不是依赖用户来设置他们的时区。 他们中的许多人使用 VPN 和旅行。

当有人更改时区时，我们是否可以建立足够的可供性以确保连续性不会中断？ 我认为目前只要在 36 小时的窗口内，我们就会保持这种连续性。

@QuincyLarson我可能是错的，但我认为我们不会在 36 小时内保持连胜。 Afaik prepUniqueDays 创建了一个时间戳数组，它们之间的时间为 24、48 等，我们将其与 betweenDays 进行比较，后者为 1.5 天，但唯一天数之间的差异只能是整数(1,2,...n) 所以它实际上没有任何用于计算条纹的小数。

我们如何获得 req.user.timezone？ 因为虚拟对象没有时区作为属性，所以const timezone = user && user.timezone ? user.timezone : 'UTC';始终默认为 UTC。 我们是否根据用户位置进行设置？

如果我们有 user.timezone 条纹将与 user.timezone 一致，但热图只会始终与客户端的时区一致。

当前设置的不同场景

如果用户的时区与客户的时区匹配

• 条纹和热图既准确又一致。

如果用户的时区与客户端的时区不匹配（例如 VPN、错误的位置/时区设置）

• 条纹对于 user.timezone 来说是准确的，但热图可能不会。

如果 user.timezone 未定义（用户未登录或未设置其位置/时区）

• 条纹会不准确，但热图对于客户端的时区仍然是准确的，除非他们使用 VPN。 我认为我们在这里可以做的不是使用 UTC 作为默认值，我们也可以使用客户端的时区来匹配热图。

_PS：我可能是错的，所以请随时纠正我。_

@Kenneth-LJS 我的印象是我们允许额外 12 小时的回旋余地，但这可能已经改变了。 如果您一直在仔细查看代码，我相信您对它如何组合在一起的理解。

关于您的情况，日历略有偏移是可以的。 很少有露营者注意到这一点或抱怨它。 露营者不会那么介意。 但是，打破连续记录是不行的——这就是导致如此多的露营者写信抱怨这个错误的原因。

所以我的论点不是试图找出时区并将它们同步，我们只是将时间标准化为美国东部标准时间 - 这是大多数美国人居住的地方 - 并增加 12 到 24 小时的余地以减少某人无意中结束他们的可能性旅行时的连胜。

嗨，我写这篇文章是因为我看到了@QuincyLarson对这篇文章的评论。

我是一名新露营者，我有一个“连续 5 天”的活动，活动在以下方面得到认可：
Jan18 - 5 项目
Jan19 - 24 项目
Jan20 - 16 项目
Jan21 - 2 项目
Jan22 - 7 项目

我从上面的阅读中看到，预计“日历完成”日期会被抵消，但我的连续记录只显示了 1 天。

===
旁注 - 感谢您的出色工作。 这是我学习编程的第 5 次尝试，但我认为这个程序能让我度过难关！

@kennethlumalicay请看看这个。 知道什么可能导致@ApeCogs的问题吗？

@ApeCogs你知道你在 1 月 21 日和 22 日完成每个挑战的时间吗？（即使是粗略估计）你的时区是什么？ 你也使用VPN吗？

@kennethlumalicay - 1 月 21 日大约是美国东部时间 22:30 - 23:30。 1 月 22 日应该是美国东部时间 09:00 - 10:00。 我有时确实使用 VPN，但它是为了工作，而且该地区不会改变（东部）。

我有问题。 当我在 22:00 CST - 24:00 CST 左右进行挑战时，通常会发生这种情况。 虽然我在周日 19:00 CST - 20:00 CST 完成了连胜，但我已经失去了连胜纪录。 当我连续 7 -8 天左右时，这通常也会发生。 不使用VPN。 如果有什么我可以做的更多帮助，请告诉我。

@ApeCogs我使用了一些虚拟数据，但似乎无法重现它。

时间戳：

Wed Jan 24 2018 22:30:00 GMT-0500 (Eastern Standard Time)
Wed Jan 24 2018 23:30:00 GMT-0500 (Eastern Standard Time)
Thu Jan 25 2018 09:05:00 GMT-0500 (Eastern Standard Time)
Thu Jan 25 2018 09:12:00 GMT-0500 (Eastern Standard Time)
Thu Jan 25 2018 09:20:00 GMT-0500 (Eastern Standard Time)
Thu Jan 25 2018 09:30:00 GMT-0500 (Eastern Standard Time)
Thu Jan 25 2018 09:39:00 GMT-0500 (Eastern Standard Time)
Thu Jan 25 2018 09:40:00 GMT-0500 (Eastern Standard Time)
Thu Jan 25 2018 09:43:00 GMT-0500 (Eastern Standard Time)

我用 24 和 25 而不是 21 和 22 来重现你的“今天”和“昨天”。

结果：

@mriel你也失去了目前的连胜纪录吗？ 您能否提供包含热图和条纹的更大屏幕截图？

重新开放，因为正在进行的讨论

@kennethlumalicay这是我的截图：

大多数情况下，我以前的连续记录是 7-8 天。 第二天我将在晚上 18:00 CST - 22:00 CST 之间上一节课。 第二天它会说我目前的连胜纪录是 1 天。

我已经开始记录当前的连续记录、日期、时间和挑战。

在这里，它说您在 20 日做了某事。

但是这里没有 20 号。

所以我假设您的时间戳显示的时区错误。

    // timezone of signed-in account
    // to show all date related components
    // using signed-in account's timezone
    // not of the profile she is viewing
    const timezone = user && user.timezone ?
      user.timezone :
      'EST';

因此，如果您未登录，则用户将为空，时区将为“EST”。
即使您已登录，我也不确定user.timezone确实存在，因为它不存在于我本地数据库的虚拟数据中。 Idk 如果 fcc 的数据库不同，但由于您仍然得到错误的时区，那么您仍然可能得到“EST”。
我假设这在默认情况下总是转到“EST”。

~所以我通过将 'EST' 更改为moment.tz.guess()提交了一个可能的修复。~

我刚刚做了一个挑战。 这是我的状态：
2018 年 1 月 25 日下午 20:41 CST 反向阵列与 .reverse

我观察了上周挑战是如何记录的，基本上看到挑战日期和连胜是按照 UTC 进行的，并且热图使用的是 EST。 这意味着我和 CST 的其他人需要在下午 6 点之前进行挑战，以便在同一天计算所有部分。 如果我在一天早上和第二天晚上进行挑战，那就告别连胜。

只是想一想，我使用的语言学习程序在连续记录信息旁边还有一个小时的倒计时。 有一张纸条，上面写着“通过……完成课程以保持连胜”。 将同样有用。 我将获得一致的时间称为连续问题的首要任务，但是让人们知道他们当天的截止日期比担心调整 TZ 以进行旅行或允许宽限时间（听起来不错）更有用。

一个让惊人的 100DaysOfCode Challange 毫无用处的错误

这是我的个人资料： https :

我的连续 69 天无缘无故被打破

@QuincyLarson兄弟，这是什么，我们可以扭转这个吗？！
我在24:00后两个小时提交了作品，我不认为这是一个时区错误，即使是FCC的这么多人怎么可能没有修复这个错误？

我真的很失望，我对这个 100DaysOfCode Challange 充满动力，我已经完成了所有前端项目和其他所有事情，我只有 4 个高级算法需要解决才能获得我的前端证书，我花了这么多小时没有睡觉为了保持连胜...

截屏

100DaysOfCode Challange ，如果这样的错误持续存在，它只会毁了我们的士气。

@JohnnyCheung1989看看我的进步，因为这个错误毁了我的连胜纪录:(

视频挑战似乎也不计入连胜，而是计入热图中。

我是一个初学者，尤其是生产代码。 不知道这个算法是否会产生太多的开销......但是既然热图似乎工作正常，为什么连胜算法不能只检查热图几天的绿色或走另一条路并检查灰色间隙并返回一个值，例如检查元素是否为“#cccc”等。如果是，则中断连胜
一起删除所有当前的连续逻辑时区和数学，然后以某种方式检查热图以了解元素中的颜色...
如果 ！ 灰色连续 ++ 如果灰色停止连续然后检查连续是否比最长连续长？

如果之前有人提出过这个问题，请原谅我。

我从未见过不准确的热图，但我的条纹很好......没有那么多。

或者以某种方式在热图代码中放置一个标志并且连续输出无法检查和更新？

@dverdin83
我只是简单地看了一下代码。 热图是一个插件，因此不应编辑热图代码，因为如果更新它会中断。 至于计算绿色，插件似乎是动态构建颜色的，所以你需要添加一个回调来延迟计算。

最好检查与热图相同的内容，这是Motardo建议的

关闭此问题以支持https://github.com/freeCodeCamp/freeCodeCamp/issues/17299

有谁知道连胜计数器和热图使用哪个时区？ 我只是失去了，即使我通过下午15:45 KST（UTC 0900）完成了挑战74天连胜。 连胜仅显示 1 天，但热图上今天的方块显示为绿色，并且在时间线上，挑战也记录为今天已完成。 似乎连胜计数器使用的是一个时区，而热图和时间线使用的是第二个时区。 有人可以确认吗？ 这真的很令人沮丧，因为我为看到这个数字每天都在增长并能够与朋友、家人和潜在雇主分享而感到自豪。

我知道修复可能不是一个高优先级，因此至少了解连续性规则真的可以帮助我理解并相应地调整我的编码。

引自@sgrayme https://github.com/freeCodeCamp/freeCodeCamp/issues/7925#issuecomment -361716788

我观察了上周挑战是如何记录的，基本上看到挑战日期和连胜是按照 UTC 进行的，并且热图使用的是 EST...