Tell us what’s happening:
I keep failing only one test:
The date property of any object in the log array that is returned from GET /api/users/:_id/logs should be a string. Use the dateString format of the Date API.
However, as far as I can tell, all of my logs return dates as strings, formatted with .toDateString(), and they all match the originally-inputted dates. I’ve added a function to ensure that all logs returned include these things, and I’ve output all incoming and outgoing dates to the console, but I do not see anything wrong.
Does anyone have some insight into what I may have missed?
The date property of any object in the log array that is returned from GET /api/users/:_id/logs should be a string. Use the dateString format of the Date API.
…is passing.
The only one that is failing for me locally is…
The response returned from POST /api/users/:_id/exercises will be the user object with the exercise fields added.
It looks like it has to do with how your handling returning the date value in the response. For example if I attempt to post the following to /api/users/:id/exercises:
Not the returned date is a day behind what was posted in the form. This is occurring because the date value when stored in Mongo is stored in UTC time.
So when you return the newly saved exercise and pass it to your formatDates() function and you call toDateString() on the UTC date value it gets converted to a date string in the local timezone.
I believe you will need to remove the timezone information information on the UTC value coming back from Mongo before calling toDateString() to make sure that the date value returned in the request body lines up with what was posted in the form.
Something like this:
res[key] = new Date(obj[key].toISOString().split('Z')[0]).toDateString()
How would I know the client’s time zone? As far as I know, this information is not provided by any request headers, and there is no option to choose a time zone in the form.
Project passes right now for me. It’s the timezone offset problem as mentioned in the forum.
As you wouldn’t have access to the client’s timezone from just HTTP requests in general, the best thing to do is to use an actual Date object so it can be localized appropriately without worrying about time zone differences, but you can’t do that for this project since it isn’t designed that way. You don’t have to know the “client’s” timezone in general as you are the client running the tests and you know your timezone. You could add code in the server to account for that, but I just usually run the tests when the local date and UTC date are the same.
Or, since any submitted dates are strings, you could store them that way and not convert them to Date. No offset issues with strings.
I don’t think you need to know the client’s time zone. You aren’t really asking the user to input a time so maintaining the time offset here doesn’t seem important.
I think you just need to remove the utc time zone information when presenting the date back to the user so that the timezone offset doesn’t skew what the toDateString() function returns causing an issue with the test.
Probably best practice would be to treat the user input in the form as a date and time object in the users locale timezone, get that value in utc time, store that utc value in mongo, and then present it back to the user in locale timezone which the toDateString() function can handle for you.
It appears that the problem is indeed caused by the test getting an unexpected date, rather than a poorly-formatted or non-string date.
In the case of a manually-entered date, I could store it as the originally-entered string, and it would surely return the expected date when the logs are accessed.
The majority of test cases seem to involve entering no date at all, and expecting the app to default to today’s date. It sounds like you are saying that I should manually offset the date according to my timezone so that the date returned in the exercise logs will match the current date on my local machine.
However, according to @camperextraordinaire , the project might be randomly audited by FCC. If my timezone is +9 (Tokyo), and the tester’s timezone is -7 (San Francisco), there is a high chance that the date returned will be one day later than expected, is there not?
Yes, there is and it affects my string idea I spitballed earlier. It sounded good anyway, at the time.
The typical way to do this is to ask the user for their time zone. There is no HTTP header with the local time zone. It’s not submitted as part of the date. Inferring the local time zone for anyone other than the project’s author requires using geo-IP lookups, which seems beyond the scope of the task.
The test that causes this problem (the one with dateString in the description) generates it’s date used for checking the server response with toDateString() which returns the localized date. It then posts the exercise without the date and finally compares the locally generated date with the date generated on the server, which is likely in UTC. All the logs tests are setup this way and this one is the only one that actually checks a date for equality that isn’t posted to the server.
I’m really at a loss for how to handle time zone offsets on these dates without any time zone information from the client (trivial if I control the client…). At this point someone is going to have to tell me what I’m missing (DM me if I’m just missing something obvious) because this looks a lot more like a bug in the test involved (it should be posting the date to avoid the problem) than the “issue” I have referred to it as in the past. If date generation on the server is to be tested, then a test could compare the UTC date generated locally with the server supplied date (when the date isn’t posted).
By any chance has anyone been able to solve this issue? I’m currently working on it and it appears that I have the same problem. Any help would be great thanks!
Here’s the link to my project if anyone wants to give it a look…