A date string is valid if can be successfully parsed by new Date(date_string) .
Note that the unix timestamp needs to be an integer (not a string) specifying milliseconds .
In our test we will use date strings compliant with ISO-8601 (e.g. "2016-11-20" ) because this will ensure an UTC timestamp.
So does new Date("2015-12-15") parse correctly?
According to their sample URLs, that is something your API handler should accept, yes.
Okay, right. I think I was a bit confused by the instructions.
1: When you pull values from the URL, are they strings or numbers?
2: The console.log doesn’t seem to work inside the get function. So I’ve been testing my code outside the get function:
var case1 = "2015-12-25";
var case2 = 1450137600;
var case3 = "1450137600abcdefg";
var output1 = new Date(case1); //Convert to a date.
var output2 = new Date(case2);
var output3 = new Date(case3);
var reput1 = output1.getTime(); //Get time from date.
var reput2 = output2.getTime();
var reput3 = output3.getTime();
…
Originally I had something like this. It worked on case2 and case3 (with an else statement), but not for case1:
var output = Number(req.params.input); //Convert input to a number.
var reput = new Date(output); //Create a new date.
reput.toUTCString(); //Convert to UTCString.
{"unix":reput, "utc":output}
Howdy, @adam-weiler . You’ve probably guessed by now, but for anyone else coming across this…
1: When you pull values from the URL, are they strings or numbers?
Values from URLs are strings.
I worked the problem much like you did, since the Glitch console didn’t print anything, I just tested stuff in the Chrome dev tools console. This is what I tested:
var x = '12-01-2015';
Number(x) // NaN
isNaN(Number(x)) // true
x = '1450137600';
Number(x) // 1450137600
isNaN(Number(x)) // false
Thanx! Yes I figured it out and was able to finish this project about 3 or 4 weeks ago. It makes sense, since URLs are strings and even if they contain numbers they’d still be “string” characters.
The dev tools console is a good idea too. I tend to console.log a lot just to tell what’s going on!
If you like console.log(...), just wait – there’s more! In addition, you can send error messages with console.error(...), possible problems with console.warn(...), generic info with console.info(...)… Yup, console are your FRIEND!! I mean, you can do all those with console.log, but you get pretty colors with warn and error, so.