Successfully parsed dates: timestamp microservice

I was having trouble passing the following condition:

Your project can handle dates that can be successfully parsed by new Date(date_string)

Upon trying the solution in the hints, it still does not pass this condition and I can’t figure why. Is it possibly something to do with Timezone? As when I look at /api/timestamp/05 october 2012 I get the following:

UNIX: 1349391600000
UTC: “Thu, 04 Oct 2012 23:00:00 GMT”

githubLink: GitHub - Joshie-Finster/Timestamp-Project

My code is the suggested solution now, as I abandoned my solution whilst trying to figure out why the given one wouldn’t work!

User Agent is: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:86.0) Gecko/20100101 Firefox/86.0.

Challenge: Timestamp Microservice

Link to the challenge:

Hi,

I don’t know what’s going on but I have to enter : year-month-day or I’m getting the wrong date
On MDN I find : Date.prototype.toUTCString() - JavaScript | MDN

 dateObj.toUTCString() :  "A string representing the given date using the UTC time zone."  

UTC on wikipedia :Coordinated Universal Time - Wikipedia

Coordinated Universal Time or UTC is the primary time standard by which the world regulates clocks and time. It is within about 1 second of mean solar time at 0° longitude, and is not adjusted for daylight saving time. It is effectively a successor to Greenwich Mean Time (GMT).

Could this help you?

Greets,
Karin

Hello,

Thanks for the reply. I can enter my date in different formats into the URI and it works the same so I don’t believe that is the issue for me.

I don’t see at all why this should be failing, I feel its not to do with functionality, but rather what the test is looking for; as functionally I can handle dates that can be successfully parse by new Date (date_string)

Hi,

I downloaded your project and 'm working on it. Will get back to you.

Greets,
Karin

I have a project where I was implementing the tests for the microservices projects (like the bundle for the HTML/front-end projects) and this test was problematic for the reasons you found. One comment in my source for this test:

// This test needs work because the input format does not
// guarantee UTC and will cause offset errors.

which I fixed by mucking about with the timezone offset. But on the timeserver side, it just worked.

Your code here

    res.json({ unix: dateInt.valueOf(), utc: new Date(dateInt).toUTCString() });
  } else {
    let dateObject = new Date(dateString);

    if (dateObject.toString() === "Invalid Date") {
      res.json({ error: "Invalid Date" });
    } else {
      res.json({ unix: new Date(dateObject.valueOf()).getTime(), utc: dateObject.toUTCString() });

shows you are not using the same res.json() for both paths here. I would go into this part of the route and console.log() the input and the outputs and then rerun the fCC tests to see exactly what is happening.

Hi,

timezone offsets are beyond my understanding and your code is a lot more elegant than my solution was. But I did pass using this function : Date.parse()

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse
The Date.parse() method parses a string representation of a date, and returns the number of milliseconds since January 1, 1970, 00:00:00 UTC or NaN if the string is unrecognized or, in some cases, contains illegal date values (e.g. 2015-02-31).

Could you try with that?

Greets,
Karin

Thanks for replying! Whilst my code was similar, this is mainly the solutions code now, as my interest has been gripped with why the solution itself doesn’t pass the tests! As frustrating as it is, I am enjoying the error finding.

Where did you pop Date.parse() in? I thought new Date() implicitly called Date.parse(), so should be funcitonally the same?

Thanks for the reply Jeremy. Its reassuring to hear that the timezone thing can be an issue in other projects, do you think its an offset error in this one? I’ve been running the test from a localhost port rather than an online hosting service.

I had a look at the res.json() paths you mentioned and from what I can tell, its handling input and output correctly, and parsing the dates correctly - but still fails the test.

I got this test to pass finally. Didnt change the code, but hosting on a service like Heroku solved my issues with the one test passing.

Good to hear. I believe it is an offset issue that doesn’t happen if you’re hosted on heroku or repl.it with the system properly set in UTC (to match the fCC servers). I would guess that running the code in a client or other environment with system time set to the local time could cause the problem that you had and that I worked around in the browser.

1 Like

Hi,

Great that you found a solution. I hadn’t noticed your reply.
I use Date.parse() on dates with letters in it. It returns either a date or ‘invalid date’. When there are no letters in it, I use split() and Number() to create a date.

Greets,
Karin

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