Freecodecamp: Timestamp Microservice fails working projects if the user's clock is set wrong

[jsilvao]

The empty date tests (the last two tests) never succeed, even if meeting the tests demands. I've checked this manually using the browser with my Glitch project URL https://lean-shroud.glitch.me/api/timestamp/ which is to query the API with an empty date and it correctly returns the current datetime in Unix and UTC format.

I've checked the tests source:
getUserInput => $.get(getUserInput(''url'') + ''/api/timestamp'').then(data => { var now = Date.now(); assert.approximately(data.unix, now, 20000) ;}, xhr => { throw new Error(xhr.responseText); })
getUserInput => $.get(getUserInput(''url'') + ''/api/timestamp'').then(data => { var now = Date.now(); var serverTime = (new Date(data.utc)).getTime(); assert.approximately(serverTime, now, 20000) ;}, xhr => { throw new Error(xhr.responseText); })
to make sure I'm returning the expected object with the "unix" and "utc" props and that they also contain the correct value, and they do, however, this line seems to fail assert.approximately....

• Browser Name: Google Chrome
• Browser Version: 72.0.3626.81 (Official build) (64 bits)
• Operating System: Windows 10 Pro

[ojeytonwilliams]

[project_url]/api/timestamp/:date_string?, but the tests fails for this endpoint, however, it works for the endpoint [project_url]/api/timestamp/:date?, anyone following the official description would fail on and on at the tests (like I've been having for hours).

:date_string and :date are both placeholders, so it should work equally well for both. You can name your parameter whatever you want and it will appear in req.params.

Second, the empty date tests (the last two tests) never succeed,

When I submit your project url, https://lean-shroud.glitch.me/, on https://www.freecodecamp.org/learn/apis-and-microservices/apis-and-microservices-projects/timestamp-microservice all the tests pass. Would you mind recording a video of it failing? Ideally with the dev console open so we can see any errors.

[jsilvao]

Sorry for the delay, yes, I will record a video as you asked.

[jsilvao]

@ojeytonwilliams I have a suspicion that the issue might be regarding different timezones, maybe Glitch is serving you from a different geographical location than it's serving me. This is what I've got right now, {"unix":1574274409782,"utc":"Wed, 20 Nov 2019 18:26:49 GMT"} when querying https://lean-shroud.glitch.me/api/timestamp/ would you mind checking if the response you get is the same or at least close enough?

[ojeytonwilliams]

I just got {"unix":1574275119036,"utc":"Wed, 20 Nov 2019 18:38:39 GMT"}, which was correct. It is UTC, after all, so it should not care about timezones.

[jsilvao]

@ojeytonwilliams here's the video you requested. Let me know if you need anything else (like a higher-res version). And tell me what you think about it.

[ojeytonwilliams]

I can't see anything that would cause that, yet. Could you do the same and screenshot whatever appears in the dev console (f12 on Chrome) when you do so? There should be messages like:

that can help get to the bottom of this.

No need to record another video, though!

[jsilvao]

@ojeytonwilliams the console of the DevTools is blank, no errors whatsoever. I'm simply out of words, I come from the world of C/C++ and this bug baffles me more than the most dark and elusive memory/pointer bugs I've faced.

[ojeytonwilliams]

Okay, I think your original idea

this line seems to fail assert.approximately....

is mostly likely correct, since that would result in the tests failing without any logs. AssertionErrors are not reported to the console, since the site already tells you if a test is failing.

I'm not sure why this would be the case, but potentially your system clock is out of sync with Glitch, so is reporting a UTC that's more than 20s away from the server time. So, first thing I would suggest is to synchronize your clock. If that doesn't help, we can explore other options.

[jsilvao]

@ojeytonwilliams holy st syncing the clock worked!!! Thanks so much. I still have much to learn from web proramming. Following up on that, one question, my date and times where matched perfectly but my computer (Windows 10 Pro) had a different time zone (mine is UTC-5), so, if the date time matched how is it that the timezone mattered if the tests only check for the date time. And, how is that my timezone and datetime affects the datetime/timezone reported by Glitch, isn't it supposed to return **it's local datetime? How is my datetime relevant for this? Looking forward to know (and to finally close the issue :-) ).

[ojeytonwilliams]

@jshaolin I'm afraid I'm just guessing, but it sounds like your computer's internal clock simply had the time wrong. Even if you change your timezone, that doesn't change what the computer thinks UTC is. You can test this in any dev console.

Date() // Current date and time, set at your timezone

(new Date()).toUTCString() // Same, but in UTC/GMT

If you change your timezone the first should change, but the second should not. That said, I'm not on Windows, maybe it does things differently, but I doubt it!

So, to answer your question - neither your machine nor Glitch should be returning their local time, everyone should be using UTC.

Given how difficult it was to debug this, I think a PR would be useful. Something to warn people they need to make sure their clock is right, if the last two test fail.

[jsilvao]

@ojeytonwilliams I agree on a PR. But, about getting the clock right, I think the last two tests (and that user story) should be changed to something new, something that if it fails, it would be because of some bug in the code and not because some missalignment in your computer clock. It sounds ridiculous but what if someone can't change its clock settings (lack of permission, or some other reason). A warning is nice, but I'm not so sure it's a permament solution.

Also, I'd like to quote this post of the fCC forum relating to the same issue.

"lucassorenson, post:4, topic:324997"
Very weird… I did that, and those 2 tests didn’t pass… Then, I went to your project page and entered a blank time, and it responded with the current time (like it’s supposed to). Then I went back and retested… and it passed all the tests. Try testing your project, then opening this in a new tab: https://practica1-timestamp-microservice.glitch.me/api/timestam
Then test again.

This project can fail in a obscure way, as we already experienced.

Thanks so much for your help and let me know if I can close the issue already or if I should leave it open until the PR is accepted.

[ojeytonwilliams]

@jshaolin it's a tricky one to solve permanently. Perhaps the solution is to relax the restrictions somewhat. Currently it accepts dates that differ by up to 20 seconds, so we could make it accept a wider gap (a day, maybe?). That way anyone whose clock is a little bit out will still pass, but we won't end up allowing all submissions through. Bright ideas are very welcome!

Thanks so much for your help and let me know if I can close the issue already or if I should leave it open until the PR is accepted.

You're very welcome, thanks for sticking with me through the debugging process! Please leave this open, the PR will close it automatically when it's merged.

[jsilvao]

@ojeytonwilliams

so we could make it accept a wider gap (a day, maybe?)

I think the possibility that a user clock to be offset by more than a day is very low, so maybe that would work. However, I think the root of the issue is the user story itself: to respond with the current date; maybe changing it to something else. I think that merely returning new Date() does not bring something new in pedagogical terms. So, perhaps changing/removing that user story altogether, or simply returning something unambiguous as a predefined string/date.

Maybe to use a (free) third-party service like _worldtimeapi.org_ to return a datetime for a specific region of the world and free the user of any possible clock mismatch. This approach also has the benefit of requiring the user not to just design a microservice, but also to consume one, so it brings something new to learn.

thanks for sticking with me through the debugging process!

No sweat. Besides, why wouldn't I?

[ojeytonwilliams]

Maybe to use a (free) third-party service like worldtimeapi.org

I think that's best avoided, since we don't control it and can't fix it if it goes down. You can imagine the frustration it would cause if someone can't pass the tests and there's literally nothing they can do about it.

Changing the user story could work, though we shouldn't change the difficulty too much. Unless there's a consensus it's currently too difficult/too easy, of course.

@moT01 @RandellDawson @thecodingaviator @Manish-Giri any thoughts on this? Quick summary: the Timestamp Microservice project's last two tests can fail if the user's clock doesn't have the correct time and we're considering fixes.

[moT01]

A simple fix might be to relax the 20 seconds like suggested.

We could make our own api to return the date. Meaning instead of checking the clock on the users computer, we make an additional request to an api we build that returns the date so we can be sure of its accuracy. Although, theoretically, this should work every time - it does complicate the code. Side note: glitch is probably not the best place to host that since it will go to "sleep" and the test may timeout, leading to confusion. So it may need to be on the fCC server or somewhere it is always running.

[moT01]

Closing this as stale. If someone wants to continue the discussion, feel free to leave a comment and we can reopen this. Thanks and happy coding 🎉