Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Time mismatch #10154

Closed
osenvosem opened this issue Aug 10, 2016 · 10 comments
Closed

Time mismatch #10154

osenvosem opened this issue Aug 10, 2016 · 10 comments
Labels
help wanted Open for all. You do not need permission to work on these. type: bug Issues that need priority attention. Platform, Curriculum tests (if broken completely), etc.

Comments

@osenvosem
Copy link

I made one challenge (Word Blanks) several minutes after 00:00 according the local time and found the time mismatch:

screen shot 2016-08-11 at 00 20 10
screen shot 2016-08-11 at 00 20 27

@texas2010
Copy link
Member

texas2010 commented Aug 10, 2016

What is your timezone? if your time is pass after midnight. it will be August 11, 2016.

@osenvosem
Copy link
Author

osenvosem commented Aug 10, 2016

@dwd2010 +3, Moscow time. On the first screenshot it is August 11, but in the list of challenges it still August 10.

@osenvosem
Copy link
Author

Now it's clear. List of challenges uses GMT +0 time, but graphical representation — local time (GMT +3 in my case). And this seem to be a bug.

@raisedadead raisedadead added type: bug Issues that need priority attention. Platform, Curriculum tests (if broken completely), etc. help wanted Open for all. You do not need permission to work on these. labels Aug 11, 2016
@raisedadead
Copy link
Member

I have seen this a couple of times too earlier, any one up for looking into this?

@Locheed
Copy link
Contributor

Locheed commented Aug 11, 2016

I'm no pro with this, but FreeCodeCamp uses old moment.js (from last year) and moment-timezone.js's, specially moments.js has gotten huge amount of fixes. This might have been already fixed there. Update?

@BerkeleyTrue
Copy link
Contributor

BerkeleyTrue commented Aug 15, 2016

@raisedadead Isn't this a duplicate issue?

@dhcodes
Copy link
Contributor

dhcodes commented Aug 24, 2016

This could have something to do with #7925 which I have experienced lately and also may be timezone related. I did see in the codebase that there is an err that references moment/moment-timezone#294 that is since fixed in version 0.5.1 of moment-timezone. FCC is currently on version 0.5.0 and the most current version of it is 0.5.5. That may fix this issue, though I have not tested it in this particular case.

Regarding #7925, I wonder if this line:
const daysBetween = 1.5;
in /server/utils/user-stats.js has something to do with the streak issues.

The way I read it, the determining factor of the streak is a completed challenge in the 1.5 days, but a typical user may work on something early in the morning (ex. 7 a.m.) and then jump back on the next evening at 10 p.m. and see that as still completing a challenge each day and thus, continuing the streak, even though those times are > 1.5 days apart (in this case, 39 hours). 1.5 days being 36 hours.

That's my reading, though, which is still rather green behind the ears and could be wrong.

@r1chard5mith
Copy link

fwiw, I have this precise issue. My experience agrees with @dhcodes suggestion. I was filling in the little boxes every day, but my streak got broken because I worked in the morning one day and the evening the following day. I am in Australia.
screen shot 2016-09-01 at 10 08 57 pm

@lucasreta
Copy link

agreeing with @r1chard5mith & @dhcodes here, came looking for this. Seemed off for it to be a timezone issue, given that the display works ok and separates challenges done correctly by day to the hour (I've mostly coded at or around midnight, so I've seen this live). I think it could be solved by using a 48 hour period (2 days instead of 1.5, if that's where the error was) and get the user timezone involved in the checking to see if it fits the "streak" conditions.

@raisedadead
Copy link
Member

Closing in favor of #7925

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Open for all. You do not need permission to work on these. type: bug Issues that need priority attention. Platform, Curriculum tests (if broken completely), etc.
Projects
None yet
Development

No branches or pull requests

8 participants