Change:
}; ``` <del> 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 </del> <ins> 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) </ins> ```js (getUserInput) =>

Discussion:
The test requires that the value is of type Number. But you have to look at the example response given and realize it is a number and not a string. We do pretty often get forum posts about this so maybe this needs to be made more clear? Challenge:
I feel like observing the behaviour of the demo API and figuring out how your own API differs from the spec is an important part of the project, where giving too much information up-front might not be desirable because then people can complete it on autopilot instead of having learning experiences. There is something to be said more generally though about the current difficulty in debugging why your code fails one of the project requirements, as unlike the Frontend Libraries Cert you can't see the actual output of any failed tests.
I completely agree but it would be nice if the test blocks were formatted a bit better. Like the response on its own line using a fenced code block with some highlighting. I know it would make it take up more space but I think that would be worth it. Just as an example: ! Although, I don't think providing the types in the specs is that unreasonable either.
BTW, the type is provided for the other response: I'm not suggesting we spoon-feed the students, just that we give them clear instructions.
Personally, "in milliseconds" suggests it should be a number to me. But that could be more due to my experience than anything else. I don't see a reason why this shouldn't be clarified, so I'm on board. Maybe just adding a note will work?
I would be fine with just a mention of the type in the message. Edit: maybe (as type Number) just to avoid any confusion?
Works for me! Will go ahead and open up for first timers. This looks like something that can be fixed by "first time" code contributors to this repository. Here are the files that you should be looking at to work on a fix: List of files: Please make sure you read , we prioritize contributors following the instructions in our guides. Join us in or if you need help contributing, our moderators will guide you through this. Sometimes we may get more than one pull request. We typically accept the most quality contribution followed by the one that is made first. Happy contributing.

I created a full-stack JavaScript app that is functionally similar to this: https://timestamp- you can check it at github repo I also requested a pull. and how it works I uploaded a video , please accept my pull request and merge it https://user-
This is an issue about adding type information to one of the test output blocks. We do not merge people's projects. You submit the project on the challenge page and it gets tested.
ok but there's a problem that every time after refresh it changes its localhost port because of this it's hard to deploy it
Please use the if you need help with the curriculum.