Timestamp Microservice - Feedback

Hi,

Here’s my Timestamp Microservice on Github and the app on Heroku.

Your feedback is very much appreciated! :slight_smile:

Thanks

Looks great! I just finished mine too. :slight_smile:
https://lit-taiga-89524.herokuapp.com/

Good work @flavia.rodriguesf and @AdventureBear!

It’s a pretty steep learning curve getting your first node API up and running!

sure is. I got #2 working now and will start a different thread for it. Thanks for the tip on the port, I created a template in github to speed up the startup for each one.

May I request a feedback on my first API project ?

source: https://github.com/ChaturvediSulabh/timestamp-microservice.git
url: https://sulabhchaturvedi-timestamp-ms.herokuapp.com/

https://sulabhchaturvedi-timestamp-ms.herokuapp.com/1420848

A unixdate that has a length less than 11 doesn’t work. I guess it’s the line 13: if(query.length === 11){

that could be incorrect.

It is correct. At-least for now. Length of unix timestamp is 10. May be sometime in 24th Century it would be 11. Example-: {“unix”:32850662400,“natural”:“Mon Dec 31 3010”} - Try it yourself on my app.

For more and detail information, you can refer this stackoverflow question and do read comments - https://stackoverflow.com/questions/4415631/timestamp-string-length

Cheers !!!

So in your app you need leading 000 for times close to 1970, for the unixtime stamps?

And then interesting question is that why does the app give back a time stamp without leading 000? For such a date. Just wondering.

Also what date is this, according to your app we go to a nice future date.
https://sulabhchaturvedi-timestamp-ms.herokuapp.com/142084.

Query: And then interesting question is that why does the app give back a time stamp without leading 000? For such a date. Just wondering.

Response : I have used JavaScript Date Constructor
Please refer - Date - JavaScript | MDN

Query :14284
Response: what is the expected output for this use case ? The use case seems to be invalid to me as, A Unix timestamp (or epoch time) is the number of seconds that have elapsed since January 1, 1970 00:00 UTC

Moreover, I think I should add a use case to turn everything before 1970 as invalid. Thank you

It validates it as 1Jan 142084. Don’t know if that is what you intended to do.

Well, I agree with you, it is a bug and I should fix it. The result for any such invalid dates should be 1 jan 1970. Thanks

Fixed it, once again, thanks for pointing it out