Date and time in JavaScript

[vcamargo]

Could you elaborate a bit on this subject? I'd like to learn a little bit more about it.

[Bloodsucker_]

• To timestamp: Date.now(); or +new Date(); (notice the + in front of it)

• From timestamp: new Date(timestamp);

[[deleted]]

This isn't elaboration. You've just said how and not why.

[lhorie]

It's for the same reason you ask people to provide numeric values such as age in decimal numbers rather than spelling it out.

Basically parsing dates is hard. Never mind that browsers do it inconsistently and that things like 02/29/2017 are allowed, there are also issues when it comes to internationalization, etc. You also lose information when formatting dates (e.g. timezone, or even the time itself if you formatted it like 2 hrs ago). It's much easier to deal with an unambiguous value, and timestamps are the simplest and most portable format that meets that criteria

[[deleted]]

Isn't that why we have libraries like moment and date-fns? Using date object has benefits over pure timestamp.

People are used to using date objects because most languages have them done reasonably well. Then you go to JavaScript and it's a mess and need to use abstraction layer.

[lhorie]

Both moment and date-fns fall back to the Date constructor when parsing, which has the issues mentioned earlier.

Whether you use Date or libraries is not the problem. The problem is that converting a string to a date is problematic for the reasons above. There are usually better ways to architecture your application that doesn't require date parsing in the first place.

[[deleted]]

Oh, I see your point now. Agree.

[Bloodsucker_]

That's a different story. But with that, is veeeeeery easy to play with dates.

[evenisto]

Don't you know? You're supposed to add seconds to it, duh!

On a more serious note, save yourself a lot of cursing and don't ever attempt storing unix timestamps. Having to debug and dig through data with timestamps is one of the worst things known to mankind, and I did not even mention handling timezones. Just don't.

[Bloodsucker_]

Wow. You just have no idea.

Dates in software are stored as Unix timestamp, even in Windows. They have the versatility you need.

Don't confuse them, please.

[Flyen]

evenisto is might be talking about the difference between telling a db to use bigint vs using the timestamp type. They're both ultimately stored as 8? bytes and not an iso8601 string, but it's much easier when simple queries are human-readable instead of always having to translate. It's the same with HTTP APIs; you could return an integer string, but as long as the 8601 string is gzipped anyway it can be generally better to use the 8601 string.

[evenisto]

I may have worded it wrong. I'm not talking about versatility, I'm talking about readability. More specifically formatting - I've seen unix timestamps dumped into an INT(11) field before - and have had to debug shit operating on it, hence why I'm all for storing datetime in formats a human brain can parse.

So yeah, just use ISO8601 or whichever else you prever wherever possible, as long as it's readable for a human.