5 ms·

My favorite is the date, where you months are 0 to 11, and days are 1 - 31. Along with optional semicolons, and there's this[1]: true == 1 → true

My favorite is the date, where you months are 0 to 11, and days are 1 - 31. Along with optional semicolons, and there's this[1]: true == 1 → true true == "1" → true false == 0 → true false == "0" → true false == undefined → false false == null → false null == undefined → true "\t\r\n" == 0 → true "\t\r\n 16 \t\r\n" == 16 → true "\t\r\n 16 \t\r\n" == "16" → false var a = "foobar" var b = typeof a → 'string' var c = a instanceof String → false [1] https://whydoesitsuck.com/why-does-javascript-suck/ https://whydoesitsuck.com/why-does-javascript-suck/

TeMPOraL 11y ago
> My favorite is the date, where you months are 0 to 11, and days are 1 - 31. I think this is something you need to blame UNIX for. Or who knows, maybe something made even earlier. That said, there is a logic behind that. Days we usually represent with numbers. Months we often represent with names. So the month numbers are returned as an index of a sequence of names. (Not saying I like this logic, but it sort of makes sense.)
- eropple 11y ago
  > I think this is something you need to blame UNIX for. Or who knows, maybe something made even earlier. Continuing forward with bad designs doesn't absolve you from them, though. Plenty of languages avoid this--look at how .NET handles dates and times, it has no real relation to the underlying OS on either Windows or *nix.
- wvenable 11y ago
  The fact that we typically represent dates as "05/05/2016" kind of ruins the argument that we don't represent months as numbers.
- kragen 11y ago
  This was a design error introduced by, apparently, Dennis Ritchie (RIP) in the early 1970s, when ctime() was split into asctime() and localtime(), around the time UNIX was rewritten in C. It kind of makes sense in the context of implementing ctime(). But it was still a design error.

TeMPOraL 11y ago

> My favorite is the date, where you months are 0 to 11, and days are 1 - 31. I think this is something you need to blame UNIX for. Or who knows, maybe something made even earlier. That said, there is a logic behind that. Days we usually represent with numbers. Months we often represent with names. So the month numbers are returned as an index of a sequence of names. (Not saying I like this logic, but it sort of makes sense.)

eropple 11y ago
> I think this is something you need to blame UNIX for. Or who knows, maybe something made even earlier. Continuing forward with bad designs doesn't absolve you from them, though. Plenty of languages avoid this--look at how .NET handles dates and times, it has no real relation to the underlying OS on either Windows or *nix.
wvenable 11y ago
The fact that we typically represent dates as "05/05/2016" kind of ruins the argument that we don't represent months as numbers.
kragen 11y ago
This was a design error introduced by, apparently, Dennis Ritchie (RIP) in the early 1970s, when ctime() was split into asctime() and localtime(), around the time UNIX was rewritten in C. It kind of makes sense in the context of implementing ctime(). But it was still a design error.