Test fails in Timestamp Microservice

JavaScript
1

Hi! There is a test "A request to /api/1451001600000 should return { unix: 1451001600000, utc: "Fri, 25 Dec 2015 00:00:00 GMT" }" which continues to fail even when I double checked everything, including an attempt with another browser. I couldn’t find any difference in the output, maybe the text describing the test is incomplete, or you’ll point me to an error I missed (though opened the thread after exhausting other options). Who could possible help with it here, so I could share the link?

2

Can we see your code, please? Just share the link.

3

Question is raised more by output, which looks correct to my eyes. It’s improbable tests of this course checks the code itself.
Here’s the link. Didn’t comment the code, but it’s quite readable.

4

The second link has a 404 error or page not found.
The first one, I did not see anything that you are working on. It looks like the starter file that FCC provided.

5

It’s a free tier environment… Takes some time to heat up after you run the thing, tests got timeouts sometime too, btw.

The challenge solved in router.js file. Its route attached in the end of that starter file you mentioned.

6

You are right sorry for that.

In my case I test if if the parameter is empty or undefined and if it is, return the current date and time.

Now, there are several ways to use native JS Date() function. According to MDN are the following:

let birthday = new Date('December 17, 1995 03:24:00')
let birthday = new Date('1995-12-17T03:24:00')
let birthday = new Date(1995, 11, 17)            // the month is 0-indexed
let birthday = new Date(1995, 11, 17, 3, 24, 0)
let birthday = new Date(628021800000)            // passing epoch timestamp

Use regex to check if the parameter is all numbers (say 628021800000) and use one of the method above (Tip: but remember it is a string when passed so you have to do something first). If not (say 2015-12-25) use also one of the method above. If the latter check if it is an invalid date (say 2015-13-25 or 2015-12/25).

You don’t need to format the time (check getTime()) or the date (check toUTCString()).

7

Thanks for review and tips: will get back to them when I’ll reach the desktop!

But the main question is still untouched!! This solution — with all of improvements it can get — should pass. And one of the tests mysteriously fails.

8

Nothing mysterious ever happens on a computer. They are pure, deterministic logic. They always do exactly what we tell them to do.

The failing test says:

A request to /api/1451001600000 should return { unix: 1451001600000, utc: "Fri, 25 Dec 2015 00:00:00 GMT" }

And you are returning:

{"unix":"1451001600000","utc":"Fri, 25 Dec 2015 00:00:00 GMT"}

Do you not see a difference? Hint: Think data type.

Good coders are good debuggers and good debuggers are good detectives. Part of being a good detective is being able to focus on tiny little details.

2 Likes
9

Thanks, Kevin! I somehow was sure that JSON wraps all keys and values in quotes, and it’s recipient job to parse. So comparing presented object with JSON was not that helpful for me. Now I need to adjust my JSON understanding. Thanks again!

10

With JSON, keys are always in quoters. It is not required for JS keys (unless it is not a valid JS identifier, e.g., starts with a number, has a space, etc.) In JSON and JS values, only string literal values are in quotes. Number, Boolean, and null are valid JSON primitives and will never be in quotes.

11

Thanks for your help, everybody!

This method would save me half of the time on this one, I believe!

1 Like
12

We also recently updated the text for the Unix timestamp requirement (see the parentheses at the end)

A request to /api/:date? with a valid date should return a JSON object with a unix key that is a Unix timestamp of the input date in milliseconds (as type Number)

Which would be impossible if all value types were strings.

1 Like
13

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.