Challenge 15 Megathread

Hi there!

It was specified in the instructions that both the launch date and name are strings (fakeToday is a date object)

It seems annoying to convert the date string to a date object when we could receive a date object directly, and you’d be right! However, dates are not a standard structure and if you have to interact with other scripts, apis or data, you will receive it as a string, so it’s actually a common thing to do.


launchDate, missionName, fakeToday are all provided as strings. As can be observed in the example input, and explicitly stated in the day’s write-up.

fakeToday gets converted to a Date on the first line as a sort of example how you might work with a string that needs to be converted to a date.

Converting between data types is a common requirement in coding, especially in projects where you may only be responsible for a small portion of the code. Normalizing your inputs, thus, is often a requirement, and a good practice to avoid certain types of code failures.

So step 0) receive string, step 1) convert to usable types (several ways to do this) step 2) embed the result in an object. Step 3) return the object.


I believe it is specified because if you are dividing the number of Milliseconds in a day as seen in the code below (where lDate is the Date object for launchDate and tDate is the same for today).
(lDate.getTime() - tDate.getTime())/(1000 * 60 * 60 * 24)
You can possibly get a floating point result (though based on my initial test which passed, it is not being checked for).

If fakeToday is passed with the same format as the example, this is no issue, however if the new Date() executes in the first line of the function, this can in fact happen.

Case in Point:

For this result I have removed the Math.round() from my code.

As per Sonicthecronic’s suggestion in Post: Challenge 15 Megathread - #21 by Sonicthecronic, I have modified my code to use Math.trunc() instead as Math.ceil() would indicate 1 day remaining even if it is the day of the launch.

1 Like

this one got me thinking a lot ! Good challenge !

The problem says the expected output is:
missionName = “Moon visit”,
daysRemaining = 11

That’s not an object . Don’t you mean this:
missionName: “Moon visit”,
daysRemaining: 11

1 Like

I hope this helps clarify something…


It will round up OR down depending what the value after the decimal is. Up if its >= .5 and down if it is < .5


It will round up as long as there is any value after the decimal. So 1.7 rounds up to 2 and 9.00000001 would round up to 10. This might help people when it comes to figuring out how many days till the launch.

As a side note, depending on what order you have your variables in when you calculate the time difference, you may get a negative number.


This will give you the absolute value of a number. So whether you have a negative number or not, this will give you a positive number to work with. When comparing dates, who knows if the date is in the future or the past. I believe this should allow you to calculate for both.

... launchDate.getDate() - today.getDate();

For my solution, it uses a subtraction between two getDate()s from the input dates, but it would only work if the dates are of the same month from my understanding. Is that correct?


I think I might have done something stupid and wold like to begin anew.

Is there any way to ‘reset’ to the original code when I first opened the challenge?

Thank you,

Thank you for the explanation.

At first I ran the code without the Math.round( ) and it passed all tests. I did not get a fractional amount of days using :

let daysRemaining = (takeOffDate - fakeToday)/(1000 * 60 * 60 * 24);

To make it more general I then added rounding in case the launchDate included more than YYYY-MM-DD.

Yes, this only works within the same month as per the link in the hint section:

This was the code before any input from participants:

const timeRemaining = (launchDate, missionName, fakeToday) => {
const today = fakeToday || new Date(); // Do not alter this line!

// Code here!

This is what worked for me. It may look complicated and I am sure I could break it down further. But it works. Lol.

Math.ceil((Math.abs(Date.parse(fakeToday) - Date.parse(launchDate)))/(1000 * 60 * 60 * 24))

That gave me the days between the two dates. No matter what order I have the variables in (launchDate - today) OR (today - launchDate). If you reverse your variable order in your calculation, does it still pass?

1 Like

I am struggling with figuring out why I fail the first test, here is my code:

const timeRemaining = (launchDate, missionName, fakeToday) => {
  const today = fakeToday || new Date() // Do not alter this line!

  // Code here!
  let replacedLaunch = launchDate.replace(/-/g,'');
  let replacedFake = fakeToday.replace(/-/g,'');
  let countDays = replacedLaunch - replacedFake;
  return `${countDays}: ${missionName}`;

The first fail says: Reason: Your code could not run. “Cannot read property ‘replace’ of undefined”

I understand that it wants an object and I will work that part out, but why does it say it can’t read replace and that launchDate is undefined? Isn’t there a value already assigned to it like in the other challenges?

Thank you!

I think it is because you are returnning a string when it is basically looking for an array. If you assign countDays and missionName to properties of an object and then pass that object, it should work.

let objRemaining = {
   daysRemaining: countDays,
   missionName: missionName
return objRemaining;

EDIT: Nope. That didn’t help. That is an issue but the problem is with your calculation of countDays.

Instead of launchDate.replace and today.replace try Date.parse(launchDate) and Date.parse(today)

1 Like

The reason your code is failing is because fakeToday gets passed as a null in some of the test cases. You should try using the today value as this will always be defined as a Date Object.

The Lighthouse Team explained in a previous post:

This being said, though I have not tested it, I don’t think that parsing the string value of a Date Object would work. Try initializing launchDate as a Date Object (new Date(launchDate)) and using the built-in functions of the Date Object to perform the calculations.

My code would fail if I swapped the values in my subtraction calculation, however we always know that launchDate will be greater than today. Therefore there is no reason to find the absolute value of this calculation.

In my personal opinion I would also like my code to tell me if I have completely missed the launch of the rocket by getting a negative number of days past the launch date, though I do not believe that the tests are checking for this at all.

EDIT: (ran out of replies for today lol)
I re-read the requirements and it states calculate the difference, therefore you are absolutely right, Math.abs() should be there! Thanks @Sonicthecronic

I agree with you. It’s the little details, forethought and error checking that make good code. But would you not agree that coding instruction and get quite literal with the explainations sometimes? Lol, It’s not what they say, but what they don’t say that you have to watch out for.

Thank you very much !

One final thought before I take off…

"A part of the code has been written for you, and it is important that it stays the same for the tests to work out."

One thing I love about coding is that there is usually more than one way to get your answer. It is possible to do the challenge without keeping that first line of code they tell you not to delete. I was able to get my code down to just six lines. seven if you count the final bracket. Is it possible to get a shorter answer? I’m not that fluent in JS to know all the built-in functions.

you could cut it down to two lines but that does not make good code. Good code is not the fewest lines at all. Solving the problem, Readability, Efficency of the execution, Maintainability, loosely coupled, and DRY code, are some things to measure good code by. Readability and maintainability go hand in hand with self-documenting code so good variable names , function and/or objects that clearly state what they are for and what they are doing. ie. sometimes using longer syntax pulling out and defining variables for elements when needed instead of jamming things in one line allow you to read and understand your code when you or anyone else looks at it months or years from now.