Freecodecamp: Полоса по-прежнему неточна для многих отдыхающих.

Мой первый раз с открытым исходным кодом, но мне бы хотелось посмотреть, справлюсь ли я с этой задачей.

Это по-прежнему проблема, к которой мы получаем много жалоб.

@QuincyLarson Я хочу помочь

@sorlovsky Замечательно ! Мы заинтересованы в вашей помощи! Посмотрите, сможете ли вы написать несколько тестов, охватывающих различные крайние случаи. Кажется, что это работает в 99,9% случаев, но в некоторых ситуациях это не так, и я не совсем уверен, почему.

Я немного изучил это, и это может быть вызвано тем фактом, что он подсчитывает текущие серии вызовов, а не другие действия (проекты или алгоритмы). Также возможно, что это часовые пояса, как указано выше. Я собираюсь разобраться в проблеме и посмотреть, смогу ли я пиариться, если до этого никто не дойдет.

Может кто-нибудь, пожалуйста, дайте мне знать, если мне что-то здесь не хватает.

const daysBetween = 1,5; можно обновить до const daysBetween = 2; потому что логика в следующих функциях всегда говорит, что меньше daysBetween и не меньше или равно daysBetween. Это означает, что освещение будет с 00:00:00 в один день до 23:59:59 в следующий. Логика часового пояса также должна остаться прежней.

Изменение 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 года с # 6333. Решение заключалось в том, чтобы браузер отправлял часовой пояс пользователя при каждой отправке запроса. Сервер будет хранить часовой пояс и использовать его для расчета полос. Но затем, в январе 2017 года, произошел большой рефакторинг, изменивший способ отправки проблем, и исправление было удалено . Логика на стороне сервера все еще существует, просто браузер больше не отправляет часовой пояс.

@Motardo Спасибо за расследование. Хотели бы вы исправить это, чтобы исправление @LenaBarinova снова

@QuincyLarson После того, как я еще раз посмотрел и

План А
Я считаю, что старое решение не было идеальным. Для правильного просмотра своего профиля требовалось, чтобы пользователь вошел в систему, и при просмотре профилей других пользователей в других часовых поясах по-прежнему отображались несоответствия.

План Б (простой и понятный, хорошее временное исправление)
Я считаю, что более простым и надежным решением является отправка часового пояса клиентов с любым запросом на просмотр профиля любого пользователя, и сервер может рассчитывать полосы на основе этого часового пояса. Тогда не имеет значения, был ли клиент авторизован или чей профиль просматривался. Полосы и календарь всегда будут синхронизированы.

План C (сложный рефакторинг, возможная будущая дорожная карта)
Наверное, лучшим решением было бы вообще не рассчитывать полосы на сервере. Сервер должен отправлять необработанные временные метки клиенту и позволить клиенту решать, какому дню принадлежит каждая временная метка и как долго полосы основаны на местном часовом поясе. Именно так мы поступаем с данными тепловой карты календаря, чтобы они всегда были согласованными.

Я совершенно новичок в реагировании и rxjs, и я думаю, что план C не для меня, но я был бы рад сделать патч для плана B, и я хотел бы услышать другие идеи и предложения.

@Motardo Я определенно согласен, что Plan C имеет наибольший смысл.

Учитывая, что с тех пор, как вы опубликовали это, прошло 15 дней, сильно ли вы улучшили React и RXJS? Это может быть хорошей задачей для перехода на новый уровень возможностей написания сценариев на стороне клиента 😉

Привет. # 16071

Что я сделал:
Сначала я изменил расчет полос, чтобы использовать 24 часа между ними вместо 1,5 дней между ними. Затем я взял разницу в часах 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 часов свободы действий, но это могло измениться. Если вы внимательно изучили код, я бы доверял вашему пониманию того, как он сочетается друг с другом.

Что касается ваших сценариев, это нормально, если календарь немного смещен. Очень немногие отдыхающие заметили это или пожаловались на это. Кемперы не будут возражать. Но нарушать полосу - это не нормально - именно это заставило так много отдыхающих писать жалобы на эту ошибку.

Таким образом, я бы предпочел, чтобы вместо того, чтобы пытаться определить часовые пояса и синхронизировать их, мы просто нормализуем время по EST - где живет большинство американцев - и добавляем 12-24 часа свободы, чтобы уменьшить вероятность того, что кто-то случайно закончит их полоса во время путешествия.

Привет, я пишу, потому что видел комментарий @QuincyLarson к этому сообщению .

Я новичок в кемпинге, и у меня есть «5-дневная серия» мероприятий, признанных на:
18 января - 5 шт.
19 января - 24 позиции
20 января - 16 позиций
21 января - 2 шт.
22 января - 7 шт.

Из чтения выше я вижу, что ожидается смещение дат "завершения календаря", но моя полоса показывает только 1 день.

===
Примечание - спасибо за отличную работу. Это моя пятая попытка научиться программировать, но я думаю, что эта программа поможет мне пройти через горб!

@kennethlumalicay Пожалуйста, взгляните на это. Есть идеи, что может вызвать проблему @ApeCogs ?

@ApeCogs , знаете ли вы, когда вы выполняли каждое испытание 21 и 22

@kennethlumalicay - 21 января должно было быть около 22:30 - 23:30 EST. 22 января было бы 09:00 - 10:00 EST. Иногда я использую 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 до 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';

Поэтому, если вы не вошли в систему, пользователь будет иметь значение NULL, а часовой пояс - EST.
Даже если вы вошли в систему, я не совсем уверен, существует ли user.timezone самом деле, потому что он не существует в фиктивных данных в моей локальной базе данных. Idk, если db fcc отличается, но поскольку вы все еще получаете неправильный часовой пояс, вы, вероятно, все равно получаете EST.
Я предполагаю, что по умолчанию всегда идет «EST».

~ Итак, я представил возможное исправление, изменив EST на moment.tz.guess () . ~

Я просто бросил вызов. Вот какой у меня статус:
25.01.2018 20:41 CST Reverse Arrays с .reverse

Я наблюдал, как проблемы записываются в течение последней недели, и в основном видел, что даты и серия испытаний проходят по UTC, а тепловая карта использует EST. Это означает, что мне и другим людям в CST нужно выполнить задачи до 18:00, чтобы все части засчитывались за один и тот же день. И если я буду выполнять задачи утром в один день и вечером в следующий, до свидания.

Подумать только, в программах изучения языка, которые я использую, рядом с информацией о полосе отображается обратный отсчет оставшихся часов. Имея записку, в которой говорится: «Завершите уроки до ... чтобы сохранить серию». было бы столь же полезно. Я бы назвал получение согласованного времени первым приоритетом для проблемы с полосой, но сообщить людям их крайний срок на день было бы более полезным, чем беспокоиться о корректировке TZ для поездок или предоставлении льготных часов (как бы хорошо это ни звучало).

Ошибка, которая делает бесполезным удивительный 100DaysOfCode Challange

Вот мой профиль: https://www.freecodecamp.org/dardandmr

Моя 69-дневная серия прервана без всякой причины

@QuincyLarson, пожалуйста, братан, что это такое, и можем ли мы отменить это ?!
Я отправил работу через два часа после 24:00, я не думаю, что это ошибка часового пояса, даже если это возможно, что так много людей здесь, в FCC, не исправили эту ошибку?

Я действительно разочарован, я был так мотивирован этим 100DaysOfCode Challange, и я завершил все проекты Front-End и все остальное, у меня есть только 4 расширенных алгоритма, которые нужно решить, чтобы запросить мой сертификат Front End, оставалось так много часов без сна, просто чтобы продолжить серию ...

Скриншот

100DaysOfCode Challange, если такая ошибка не исчезнет, ​​это просто разрушит нам моральный дух.

@ JohnnyCheung1989 посмотри на мой прогресс с тех пор, как ошибка испортила мою серию :(

Кажется, что проблемы с видео тоже не засчитываются в полосы, но учитываются на тепловой карте.

Я новичок, особенно с производственным кодом. Не знаю, создаст ли этот алгоритм слишком много накладных расходов ... Но поскольку тепловая карта, похоже, работает нормально, почему алгоритм для полосы не может просто проверить тепловую карту в течение дней, окрашенных в зеленый цвет, или пойти другим путем и проверить серые пробелы и вернуться значение, например, проверьте, является ли элемент '#cccc' и т. д., если да, прервать полосу
Удалите все временные зоны логики текущей полосы и математику вместе и просто проверьте тепловую карту каким-либо образом на предмет цвета в элементе ...
Если ! серая полоса ++ если серая стоп-полоса, проверить, длиннее ли полоса самой длинной полосы?

Простите меня, если об этом уже говорили раньше.

Я никогда не видел неточной тепловой карты, но мои полосы неплохие ... не очень.

Или как-то установить флаг в коде тепловой карты, и выходные данные серии не могут его проверить и обновить?

@ dverdin83
Я лишь бегло посмотрел на код. Тепловая карта - это плагин, поэтому редактировать код тепловой карты не следует, так как при обновлении он сломается. Что касается подсчета зеленого, похоже, что плагин создает цвет на лету, поэтому вам нужно будет добавить обратный вызов, чтобы отложить расчет.

Было бы лучше проверить то же, что и на тепловой карте , это то, что было предложено

Закрытие этой проблемы в пользу https://github.com/freeCodeCamp/freeCodeCamp/issues/17299

Кто-нибудь знает, какой часовой пояс используется счетчиком полос и тепловой картой? Я только что проиграл 74-дневную серию, хотя завершил испытание к 15:45 по корейскому времени (UTC +0900). Полоса показывает только 1 день, но сегодняшний квадрат на тепловой карте окрашен в зеленый цвет, а на временной шкале задача также записана как выполненная сегодня. Похоже, что счетчик полос использует один часовой пояс, а тепловая карта и временная шкала используют второй часовой пояс. Кто-нибудь может подтвердить? Это действительно деморализует, так как я гордился тем, что их число растет с каждым днем, и тем, что могу поделиться этим с друзьями, семьей и потенциальными работодателями.

Я понимаю, что исправление может быть невысокой задачей, поэтому, по крайней мере, знание правил серии действительно поможет мне понять и соответствующим образом скорректировать код.

Цитируется из @sgrayme https://github.com/freeCodeCamp/freeCodeCamp/issues/7925#issuecomment -361716788

Я наблюдал, как проблемы записываются в течение прошлой недели, и в основном видел, что даты и серия испытаний проходят по UTC, а тепловая карта использует EST ...