Exercise Tracker & Confusion on Date formats for 3 different tests

Tell us what’s happening:
The date field is significant in several different tests in this project, and it seems a fundamental choice is how you decide to create your Schema, either stored as a Date or stored as a String. now it makes more sense to me to store it as a Date, but there are a few tests in which storing as a string could work as well:

  1. Returning date as a string in the api/users/:id/exercises route
  2. checking if the date field is filled out in the form, and if it is, it’s a string, if it is not, the default behavior of new Date() is a date object. So you need to either convert the form supplied string to a date, or convert the date to a string
  3. using query parameters for date. These will be supplied as strings, but I cant filter the Model.find({filter}) by strings when searching for a date range, so I’d need to convert to date, which means they need to be stored as a Date.

This brings me all the way back to #1 above, the requirement to return exercise as a String.

So I would need to simple retrieve the date and covert it to a string before returning the JSON object, right?

I’m assuming the logic behind this is that these are real world user needs that we’d need to know how to handle different types of input?

Your project link(s)

solution: boilerplate-project-exercisetracker - Replit

Your browser information:

User Agent is: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36

Challenge: Back End Development and APIs Projects - Exercise Tracker

Link to the challenge:

So basically typing this out helped me outline the simple changes that I needed in order to swap all the code around, and it passes just the same.

So I’m going to leave this here marked as solved, just in case anyone else is pulling their hair out over it. Still not passing all the tests but only have 1 to go.

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