New Date("wtf") – How well do you know JavaScript's Date class?(jsdate.wtf)
jsdate.wtf
New Date("wtf") – How well do you know JavaScript's Date class?
https://jsdate.wtf
244 コメント
Please don't make fun of JavaScript. Last time it happened, it replied with Node and now it's everywhere.
I maintain that TypeScript is probably the best language you’ll be able to get paid to write.
People may forget what you did, but they'll remember how you made them feel. It's been years since I've used TS, but I remember it failing to solve about half the problems that I had with JS. I think they did the best they could given the constraints though.
This article is a good example. TS can't fix the underlying APIs, standard library etc.
This article is a good example. TS can't fix the underlying APIs, standard library etc.
I wouldn’t blame TS for not fixing the JS standard library. It’s just a type system.
Normally, I would agree with you, but if you are going to say it’s the best language, then the criticism is fair.
Best language would be the entire ecosystem, including standard library
Best language would be the entire ecosystem, including standard library
Yes, I just think you’ve got the wrong expectations if you say “TS failed to fix half of JS’s” problems.
Kotlin and even modern Java are both preferable for me. There’s no shortage of JVM roles.
If your entire stack is using optionals then Java can be acceptable. It’s not a terrible language otherwise. Checked exceptions are a failure IMO because they only check for some types of errors.
As of the last couple years, you're probably not wrong. Basically every open role right now requires TypeScript, Node, Next.JS, etc.
Swift is a bliss to write and easy to get paid to write it.
I feel differently, but I've only tried it briefly. It feels like an abomination that can't decide what it is and has just too much syntactic sugar.
i was paid to write rust for a couple of years.
Hence the 'probably'
Meh, I used to have that feeling, especially when discovering fp-ts and then effect (neither of which I've been paid to write), but after about four years, I'm tired of writing it period. The standard library for node is horrible; the ecosystem is okay but not great. And I don't even care for effect anymore. I also write go in my job and it's just okay, but the standard library is much better.
I've been playing around with rust in my free time and like it. I think it's a good FP middle ground. Gleam also looks interesting. But to your point I imagine there aren't many jobs paying for rust and practically none for Gleam.
I've been playing around with rust in my free time and like it. I think it's a good FP middle ground. Gleam also looks interesting. But to your point I imagine there aren't many jobs paying for rust and practically none for Gleam.
I’m personally strongly opposed to using any library that becomes a new primitive of my project. I’m fine with an intrusive framework, but never a fundamental change to how plain-old business logic is written. That means fp-ts is out. However stuff like JS’s Date can be replaced under these rules - these days perhaps with a Temporal polyfill.
I believe Fly.io deploys some Gleam in prod. I tried playing with Gleam for a bit, but I got stuck trying to make the Actor Model make sense. It’s Gleam’s solution to mutable state, inherited from Erlang and the BEAM. It takes so much code just to emulate a simple, mutable Map. I liked Rust’s middle ground with `mut` in function defs.
[deleted]
C# pays fine
If you like one, you’ll prolly like the other
Hell you might even like ActionScript ;P
Hell you might even like ActionScript ;P
If you like TypeScript and C#, then you'll probably also like Delphi and Turbo Pascal!
They were all written by the same guy, Anders Hejlsberg:
https://en.wikipedia.org/wiki/Anders_Hejlsberg
https://news.ycombinator.com/item?id=19568681
"My favorite is always the billion dollar mistake of having null in the language. And since JavaScript has both null and undefined, it's the two billion dollar mistake." -Anders Hejlsberg
"It is by far the most problematic part of language design. And it's a single value that -- ha ha ha ha -- that if only that wasn't there, imagine all the problems we wouldn't have, right? If type systems were designed that way. And some type systems are, and some type systems are getting there, but boy, trying to retrofit that on top of a type system that has null in the first place is quite an undertaking." -Anders Hejlsberg
They were all written by the same guy, Anders Hejlsberg:
https://en.wikipedia.org/wiki/Anders_Hejlsberg
https://news.ycombinator.com/item?id=19568681
"My favorite is always the billion dollar mistake of having null in the language. And since JavaScript has both null and undefined, it's the two billion dollar mistake." -Anders Hejlsberg
"It is by far the most problematic part of language design. And it's a single value that -- ha ha ha ha -- that if only that wasn't there, imagine all the problems we wouldn't have, right? If type systems were designed that way. And some type systems are, and some type systems are getting there, but boy, trying to retrofit that on top of a type system that has null in the first place is quite an undertaking." -Anders Hejlsberg
> "My favorite is always the billion dollar mistake of having null in the language. And since JavaScript has both null and undefined, it's the two billion dollar mistake."
> -Anders Hejlsberg
With signed ints it even leads to symmetric ranges in the negative and positive directions.
The FORTH-83 standard changed FIG-FORTH's official value of TRUE from 1 to -1 so all its bits were set. That was a rough transition like Python 2=>3, but worth it. It also defined /MOD integer division to be floored (rounded towards -infinity instead of zero like FIG-FORTH), which was also a tough change but the right one, especially for graphics.
https://python-history.blogspot.com/2010/08/why-pythons-inte...
https://forth-standard.org/standard/diff?utm_source=chatgpt....
https://atariwiki.org/wiki/Wiki.jsp?page=Converting+FIG-Fort...
>4. For various reasons the definition of all divide functions general effect is that quotients are floored instead of rounded toward zero. This should cause no problems for most pre-existing application software. The new divide functions are marginally slower than the old (a few machine cycles under most circumstances). The side-effects of the redefinition for floored divide can be counter-intuitive under some circumstances. For example, in FIG-Forth the operation
>5. The true flag returned by all logical operations has been changed from the value 1 (in FIG-Forth) to the value -1 (in Forth-83, all bits set). If your code used the 0 or 1 returned by a comparison in an arithmetic operation, you will need to interpolate the operator ABS after the logical operator. This is a particularly difficult problem to look for in your source code. However, we feel that this mutation in the 83-Standard was beneficial as it allows the returned true/false value to be used as a mask for AND.
https://python-history.blogspot.com/2010/08/why-pythons-inte...
https://forth-standard.org/standard/diff?utm_source=chatgpt....
https://atariwiki.org/wiki/Wiki.jsp?page=Converting+FIG-Fort...
>4. For various reasons the definition of all divide functions general effect is that quotients are floored instead of rounded toward zero. This should cause no problems for most pre-existing application software. The new divide functions are marginally slower than the old (a few machine cycles under most circumstances). The side-effects of the redefinition for floored divide can be counter-intuitive under some circumstances. For example, in FIG-Forth the operation
-40 360 MOD
>5. The true flag returned by all logical operations has been changed from the value 1 (in FIG-Forth) to the value -1 (in Forth-83, all bits set). If your code used the 0 or 1 returned by a comparison in an arithmetic operation, you will need to interpolate the operator ABS after the logical operator. This is a particularly difficult problem to look for in your source code. However, we feel that this mutation in the 83-Standard was beneficial as it allows the returned true/false value to be used as a mask for AND.
Hello Don!
I always suspected that FORTH had inconsistencies in division across versions. That's why the lord told us to Go FORTH and Multiply instead.
I always suspected that FORTH had inconsistencies in division across versions. That's why the lord told us to Go FORTH and Multiply instead.
Delphi has been dead for 10+ years. Nobody uses it except for a few legacy applications and licenses cost $1200+.
You're kind of missing the point. Turbo Pascal has been dead for a lot longer. Or is it?
The point is that TypeScript and C# are extremely similar for a good reason, not a coincidence, and that Anders Hejlsberg knows what the fuck he's doing and talking about, and has been implementing amazing groundbreaking well designed languages and IDEs for a very long time. Turbo Pascal was so great it flummoxed Bill Gates, so Microsoft sent a limo to recruit and hire Anders Hejlsberg from Borland, then he made Visual J++, Windows Foundation Classes, C#, and TypeScript.
https://en.wikipedia.org/wiki/Turbo_Pascal
>Scott MacGregor of Microsoft said that Bill Gates "couldn't understand why our stuff was so slow" compared to Turbo Pascal. "He would bring in poor Greg Whitten [programming director of Microsoft languages] and yell at him for half an hour" because their company was unable to defeat Kahn's small startup, MacGregor recalled.
https://news.ycombinator.com/item?id=8664370
>"According to the suit, Microsoft also offered Mr. Hejlsberg a $1.5 million signing bonus, a base salary of $150,000 to $200,000 and options for 75,000 shares of Microsoft stock. After Borland's counteroffer last October, Microsoft offered another $1.5 million bonus, the complaint says."
The point is that TypeScript and C# are extremely similar for a good reason, not a coincidence, and that Anders Hejlsberg knows what the fuck he's doing and talking about, and has been implementing amazing groundbreaking well designed languages and IDEs for a very long time. Turbo Pascal was so great it flummoxed Bill Gates, so Microsoft sent a limo to recruit and hire Anders Hejlsberg from Borland, then he made Visual J++, Windows Foundation Classes, C#, and TypeScript.
https://en.wikipedia.org/wiki/Turbo_Pascal
>Scott MacGregor of Microsoft said that Bill Gates "couldn't understand why our stuff was so slow" compared to Turbo Pascal. "He would bring in poor Greg Whitten [programming director of Microsoft languages] and yell at him for half an hour" because their company was unable to defeat Kahn's small startup, MacGregor recalled.
https://news.ycombinator.com/item?id=8664370
>"According to the suit, Microsoft also offered Mr. Hejlsberg a $1.5 million signing bonus, a base salary of $150,000 to $200,000 and options for 75,000 shares of Microsoft stock. After Borland's counteroffer last October, Microsoft offered another $1.5 million bonus, the complaint says."
C# is nominally typed, which, in practice, leads to safer code and less type gymnastics. Of course you can avoid the type gymnastics with "any", then you you're sacrificing safety.
Agree. While people argue and split hairs over X language is better than Y language (noobs if I’m being honest, even if they have 20 yr experience), one can ship actual products and make money using TS.
It’s a good language that scales quite well to the point where you can then extract specific parts to more performant languages.
99.9% of people won’t have that problem, so I think they should just use TS and solve problems.
Anyone else can be safely ignored and they can complain in the corner.
It’s a good language that scales quite well to the point where you can then extract specific parts to more performant languages.
99.9% of people won’t have that problem, so I think they should just use TS and solve problems.
Anyone else can be safely ignored and they can complain in the corner.
I'd love to disagree, but every other language's ergonomics just seem so clunky or too magic, whereas with TS and the standard web APIs you have so much room to code how you see fit. Sure, I'd rather a LISP for purity but I'm a realist. If only Brandon Eich had really gotten his way, we'd have Scheme.
Reminding me of the near decade of WAT snark where people thought undefined behaviour was a complete proof of the futility of technology when it was actually just people mistaking what technology is. Like it isn't funny that you can't carry water with a brick but for some reason everyone thought JavaScript should be able to accommodate every possible fuckup with a specific error or just fix it. A nice goal but not something to then feel smug about when it doesn't happen but it seemed to be a viral perspective that persisted for way too long.
People aren't mad that errors aren't fixed automatically, people are mad that the behavior is inconsistent and weird for no fundamental reason other than "that's how the interpreter worked when it all started and it's too late to fix the spec now".
Python is a dynamic language as well and in many ways worse than JS, but
In JS
Python is a dynamic language as well and in many ways worse than JS, but
[] + {}
In JS
[] + {}
{} + []
First, [] + {} isn't an object, it's a string.
Second, {} + [] isn't a type conversion issue, it's a parsing issue. That {} isn't an object, it's a code block. Assign {} to a variable to ensure it's an object, then do var + [] and you get the same result as the first one.
When using an actual object in both of these, the type conversion makes sense: "+" acts on primitives like strings and numbers, so it has to convert them first. You're getting obj.toString() + array.toString() in either case.
I'll admit the parsing issue here is odd, but most of the time peoples' complaints about javascript type coercion is that they simply never bothered to learn how it works.
Second, {} + [] isn't a type conversion issue, it's a parsing issue. That {} isn't an object, it's a code block. Assign {} to a variable to ensure it's an object, then do var + [] and you get the same result as the first one.
When using an actual object in both of these, the type conversion makes sense: "+" acts on primitives like strings and numbers, so it has to convert them first. You're getting obj.toString() + array.toString() in either case.
I'll admit the parsing issue here is odd, but most of the time peoples' complaints about javascript type coercion is that they simply never bothered to learn how it works.
One can know the intricacies of how something works and still possess a valid opinion that it doesn't work all that well or defies common sense and expectations.
For me the difference is that you wouldn't then feel compelled to cynically bemoan it for retweets but this schtick went on for years where people would do something out of spec and then complain it was really bizarre to me! Anyway ... Being discouraged by a bug is fine... Making everyone else laugh at the machine on your behalf seems to against understanding and knowledge even if it is fun and funny haha
It’s absurd. Comedy is cognitive dissonance manifest. It can’t not be funny.
I don't have dissonance. The language has the features that were designed or there is a bug in what they intended and I don't know why you think adding two empty objects together should make sense anyway. That it doesn't work resolves the dissonance.
The complaint is that type coercion exists at all. It solves no problems and creates several out of thin air.
Or are you arguing that ceteris paribus you'd rather not have the language throw an error or just propagate undefined?
Or are you arguing that ceteris paribus you'd rather not have the language throw an error or just propagate undefined?
In the context of the time it was created it was fine to mess with and having an enlightened view from the future can't negate that even though I understand the complaint.
JS has had how many breaking changes since then...? They've transitioned to the future.
Why is it still here today?
Why is it still here today?
> JS has had how many breaking changes since then...?
What breaking changes has JS ever had? Its an incredibly stable language.
What breaking changes has JS ever had? Its an incredibly stable language.
Ok, lets reword that. JS has breaking changes in browsers or node at least once a year.
If the platform can continuously shift, in an ecosystem that rots faster than my veggie garden, can we not have more sensible systems in place?
If the platform can continuously shift, in an ecosystem that rots faster than my veggie garden, can we not have more sensible systems in place?
You’ve still failed to give any examples of these breaking changes. Old websites still work great.
I’ll try again. What breaking changes does JavaScript make? What are you talking about?
I’ll try again. What breaking changes does JavaScript make? What are you talking about?
8 months ago, Chrome rewrote how URLs work [0]. Which, unsurprisingly, affects the `URL` constructor in JS.
We have had so many APIs vanish from any context to "secure contexts" only. Like AppCache, or workers, or the clipboard.
Entire APIs like XMLHttpRequestProgressEvent have vanished entirely.
In fact, there is a lot of obsolete features. Enough that there's a list. [1] You can't use global or source with a RegExp anymore. You can't use the arity property on a function anymore. `Object.prototype.eval` is dead. `Object.getNotifier` is dead. `Date.prototype.toLocaleFormat()` is dead.
Old websites have been broken. Repeatedly. Or we wouldn't have, say, blogspam on why mixed content suddenly broke some Wordpress systems.
Yes, these are good changes. They're more secure. However, we're willing to break some sites in the name of security, but unwilling to fix ambiguous parsing for the programmer?
[0] https://news.ycombinator.com/item?id=41912354
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
We have had so many APIs vanish from any context to "secure contexts" only. Like AppCache, or workers, or the clipboard.
Entire APIs like XMLHttpRequestProgressEvent have vanished entirely.
In fact, there is a lot of obsolete features. Enough that there's a list. [1] You can't use global or source with a RegExp anymore. You can't use the arity property on a function anymore. `Object.prototype.eval` is dead. `Object.getNotifier` is dead. `Date.prototype.toLocaleFormat()` is dead.
Old websites have been broken. Repeatedly. Or we wouldn't have, say, blogspam on why mixed content suddenly broke some Wordpress systems.
Yes, these are good changes. They're more secure. However, we're willing to break some sites in the name of security, but unwilling to fix ambiguous parsing for the programmer?
[0] https://news.ycombinator.com/item?id=41912354
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
> peoples' complaints about javascript type coercion is that they simply never bothered to learn how it works
soo.... if the pesky people keep complaining, maybe it really doesn't make any sense? i for the life of me could never figure out why a bunch of mainstream languages a couple of decades ago decided that typing is no longer necessary and should be abolished. Is there any benefit of removing type checking (and relying on bizarre implicit coercion rules when ambiguity ensues)?
soo.... if the pesky people keep complaining, maybe it really doesn't make any sense? i for the life of me could never figure out why a bunch of mainstream languages a couple of decades ago decided that typing is no longer necessary and should be abolished. Is there any benefit of removing type checking (and relying on bizarre implicit coercion rules when ambiguity ensues)?
You will never bother me to learn something as convoluted as {} being sometimes parsed as an object and sometimes as a code block.
[deleted]
Thanks for posting this. People still don't seem to get that there's no mystery out to make their life difficult and that unfortunately everything can probably ultimately be understood in a deterministic system.
I've read your comment several times and I still don't get how I'm supposed to be frustrated by this?
> the near decade of WAT snark
For today's lucky 10,000:
https://www.destroyallsoftware.com/talks/wat (2012)
For today's lucky 10,000:
https://www.destroyallsoftware.com/talks/wat (2012)
This guy single handedly caused a wave of unproductive cynicism with this stunt. It's like the joke about all the things an everything bagel doesn't have except essentially shitting on the hard work of the entire industry by making up endless nitpicks for laughs.
Did you even read TFA? Tell me dates make even the faintest sense.
`Date` is based on the original Java `Date` class and its API was mostly copied verbatim, explaining a lot of the quirks and silliness. While JS can't remove things easily because that would break the web, a lot of work has gone into a set of time primitives that will effectively replace it. `Date`'s parsing logic is so bad even Java has deprecated it.
This is one of those cases where the problem isn't language design but boardroom politics - Sun wanted JS not to compete with Java so they had to try to make JS more like Java to present JS as a kind of "Java for amateurs".
This is one of those cases where the problem isn't language design but boardroom politics - Sun wanted JS not to compete with Java so they had to try to make JS more like Java to present JS as a kind of "Java for amateurs".
It's a fun quiz, and there's a lot of surprising behaviour. However in my opinion from a practical perspective it mostly doesn't matter.
Think hard about whether your use case really cares about local time, try and find ways to make instants appropriate. Then stick to UTC ISO 8601 strings / Unix timestamps and most of the complexity goes away, or at least gets contained to a small part of your software.
I know this isn't always possible (I once had to support a feature that required the user took a break covering two periods of 1-5am local, which was obviously fun around DST boundaries) - but in my experience at least the majority of the time you can find ways to minimise the surface area that cares.
If you're passing raw/unvalidated user input to the date parser you're holding it wrong.
Think hard about whether your use case really cares about local time, try and find ways to make instants appropriate. Then stick to UTC ISO 8601 strings / Unix timestamps and most of the complexity goes away, or at least gets contained to a small part of your software.
I know this isn't always possible (I once had to support a feature that required the user took a break covering two periods of 1-5am local, which was obviously fun around DST boundaries) - but in my experience at least the majority of the time you can find ways to minimise the surface area that cares.
If you're passing raw/unvalidated user input to the date parser you're holding it wrong.
Given that the right way to turn user input into validated input is to _parse_ it, passing it to the language feature called the _date parser_ is a completely reasonable thing to do. That this doesn't work probably doesn't surprise javascript programmers much.
Yeah this is a fair take - I guess my unwritten stipulation was don't expect anything from the JavaScript standard library to behave as you'd expect, outside of fairly narrow paths.
TBH even when working with other languages I'd skew towards doing this, possibly because I've worked with JavaScript/TypeScript too much. It's a balance but there's a certain comfort in making constraints really explicit in code you control over blindly trusting the standard library to keep it's behaviour over the lifetime of the product.
TBH even when working with other languages I'd skew towards doing this, possibly because I've worked with JavaScript/TypeScript too much. It's a balance but there's a certain comfort in making constraints really explicit in code you control over blindly trusting the standard library to keep it's behaviour over the lifetime of the product.
It's not just JS. I'm familiar with a language interpreter that used C++ stream I/O for parsing numbers. When C++ expanded the syntax for numbers it broke the interpreter in some cases. This isn't too bad if you catch it quickly but if people start relying on the new, undocumented feature it can be impossible to fix without upsetting someone.
[Small edits for clarity.]
[Small edits for clarity.]
Every time someone says "just stick to UTC ISO 8601 strings / Unix timestamp", it's clear they've only worked with dates in very specific ways.
Try that tactic with FUTURE dates.
Meet at 7pm still means meet at 7pm when timezones change, countries make changes to when their summer time starts, etc. Which happens all the time.
And it's actually a more subtle problem. You actually need the context of the timezone in some applications. If your application is showing dinner reservations, for example, you want to display the time in the local time of the restaurant, not the local time of the user. You want to know when it's booked THERE, not where you happen to be right now. I want to know my booking is at 7pm, not 1pm because I happen to be in America right now.
So using GMT/UTC is not a panacea for all the date problems you face.
It's only a solution for dates in the past. And even then you might argue that sometimes it's worth also storing the local time of the user/thing the event happened to, or at the very least the timezone they were in when it happened in a separate field.
Try that tactic with FUTURE dates.
Meet at 7pm still means meet at 7pm when timezones change, countries make changes to when their summer time starts, etc. Which happens all the time.
And it's actually a more subtle problem. You actually need the context of the timezone in some applications. If your application is showing dinner reservations, for example, you want to display the time in the local time of the restaurant, not the local time of the user. You want to know when it's booked THERE, not where you happen to be right now. I want to know my booking is at 7pm, not 1pm because I happen to be in America right now.
So using GMT/UTC is not a panacea for all the date problems you face.
It's only a solution for dates in the past. And even then you might argue that sometimes it's worth also storing the local time of the user/thing the event happened to, or at the very least the timezone they were in when it happened in a separate field.
> when timezones change, countries make changes to when their summer time starts, etc. Which happens all the time.
The frequency in which time zones are changed surprised me the first time I looked it up. For a single country it's probably quite a big deal that doesn't happen too often. But internationally there are several changes each year. I think it was like 4-6 changes per year in the past decades.
The frequency in which time zones are changed surprised me the first time I looked it up. For a single country it's probably quite a big deal that doesn't happen too often. But internationally there are several changes each year. I think it was like 4-6 changes per year in the past decades.
The IANA timezone database does occasionally revise historical rules when relevant information comes to light. So you might have calculated that some historical figure died at such-and-such a time UTC (based on a documented local time), but actually that's inaccurate and you might not know because you haven't redone the calculation with the new rules.
Are any other languages more sane with this stuff? Because I've also been to this particular corner of hell. Also in a web app.
But - wouldn't this be just as horrible in Go or Rust or any other language? (Or god forbid, C?) Are there better timezone APIs in other languages than what you can find in NPM that make these problems any easier to deal with?
But - wouldn't this be just as horrible in Go or Rust or any other language? (Or god forbid, C?) Are there better timezone APIs in other languages than what you can find in NPM that make these problems any easier to deal with?
Elixir handles all of this pretty well, for example differentiating between Date, Time, NaiveDateTime (a date and time), and DateTime (a date and time in a particular timezone). The Timex library is a great improvement too.
JS has libraries that make the problem easier too. Though you'll never find a magic library that makes all the complexity disappear, because at the end of the day, you do need to tell the computer whether you mean 7 pm on the wall clock of where the users happen to be, 7 pm on a specific date in a specific time zone, etc. and doing math between dates is inherently complex with e.g. daylight savings changes. You might end up creating a datetime that doesn't exist (which Elixir handles well).
JS has libraries that make the problem easier too. Though you'll never find a magic library that makes all the complexity disappear, because at the end of the day, you do need to tell the computer whether you mean 7 pm on the wall clock of where the users happen to be, 7 pm on a specific date in a specific time zone, etc. and doing math between dates is inherently complex with e.g. daylight savings changes. You might end up creating a datetime that doesn't exist (which Elixir handles well).
Well, Java's date time APIs are pretty good if not best in the industry.
Databases like postgres need timezone stored separately anyway, so for scheduling store local time and time zone it was scheduled in separately.
> you want to display the time in the local time of the restaurant
Many European railway timetable amd booking websites fall foul of this.
Many European railway timetable amd booking websites fall foul of this.
> If you're passing raw/unvalidated user input to the date parser you're holding it wrong.
Oh absolutely. But the difference between a sane api and other APIs is that a sane one will fail in a sane way, ideally telling me I’m holding it wrong.
Especially: the key at every turn is to fail hard if there is anything even slightly wrong rather than do something potentially incorrect. Many JS apis seem designed to continue at any cost which is the fundamental problem. You never really want a NaN. You don’t want to coerce strings to [whatever].
Oh absolutely. But the difference between a sane api and other APIs is that a sane one will fail in a sane way, ideally telling me I’m holding it wrong.
Especially: the key at every turn is to fail hard if there is anything even slightly wrong rather than do something potentially incorrect. Many JS apis seem designed to continue at any cost which is the fundamental problem. You never really want a NaN. You don’t want to coerce strings to [whatever].
I agree with this. I do think it’s an easy trap to fall into if you’re unfamiliar, and hopefully this quiz has made a whole wave of folks more familiar. :)
I agree, and/or give an option to specify the DST offset. That is sometimes useful. I was always confused that Excel did not infer the format when using CSV's though.
"If you're passing raw/unvalidated user input to the date parser you're holding it wrong."
Exactly. I would have never thought about using the Date class in this way. So the behavior is pretty much wtf and local time can get pretty complicated, but I wouldn't expect to get the right time, when passing some vague strings.
Exactly. I would have never thought about using the Date class in this way. So the behavior is pretty much wtf and local time can get pretty complicated, but I wouldn't expect to get the right time, when passing some vague strings.
The entire point of a parser is to parse unknown values. That's the entire job of a parser: take unstructured (usually string) data and turn it in to something structured, such as a date. If it can't do that reliably with error reporting then it's not a good parser on a very fundamental level.
There are so many valid and reasonable cases where this will bite you.
"Real-world data" from CSV files or XML files or whatnot (that you don't control) and sometimes they have errors in them, and it's useful to know when instead of importing wrong data.
You do something wrong by mistake and getting wrong/confusing behaviour that you literally never want, and then you need to debug where that's coming from.
The user gives you a date, you have no idea what they entered and you want to know if that's correct.
There are so many valid and reasonable cases where this will bite you.
"Real-world data" from CSV files or XML files or whatnot (that you don't control) and sometimes they have errors in them, and it's useful to know when instead of importing wrong data.
You do something wrong by mistake and getting wrong/confusing behaviour that you literally never want, and then you need to debug where that's coming from.
The user gives you a date, you have no idea what they entered and you want to know if that's correct.
A parser is supposed to reject invalid input, not generate semi-arbitrary outputs.
I agree on a theoretical level, but this is javascript and the web we are talking about. Invalid input is rather the norm in genereral, with the expectation the browser should still display something.
But I do dream of a alternative timeline, in where the web evolved different.
But I do dream of a alternative timeline, in where the web evolved different.
Let's say you're setting an appointment. The user puts in nonsense, so you helpfully schedule an appointment for a nonsense date (thank you so much, we'll get right to that in -124 years). Instead of... catching a parsing error and asking the user to try again or something? It's wild that a nonsense date would be considered for any purpose at all in a user-centric system.
Then again, I don’t think you pass user input directly into a date constructor in any language, in practice.
You decide on the format that makes sense for the user, you validate the input against that format, and then you map it into a native date.
If the date constructor supports the format you want, it’s only coincidence that makes that final mapping step simpler.
So, the native date constructor having weird behavior on invalid strings doesn’t really change real world code.
You decide on the format that makes sense for the user, you validate the input against that format, and then you map it into a native date.
If the date constructor supports the format you want, it’s only coincidence that makes that final mapping step simpler.
So, the native date constructor having weird behavior on invalid strings doesn’t really change real world code.
If you really ask me, I don't build forms that accept strings as dates from users. There is a date picker element, that can be restricted and validated.
You still need to do some validation of the input because it's difficult to impossible (in many cases) to be absolutely sure the input you receive only comes from your validated form. Even code running entirely within the browser can receive broken/malicious input from an extension, user script, or even the host OS.
It can be a bit belt and suspenders doing validation of specific forms but shit happens. It's much better to catch stuff before it's persisted on the back end or on disk.
It can be a bit belt and suspenders doing validation of specific forms but shit happens. It's much better to catch stuff before it's persisted on the back end or on disk.
That's why I wrote, "validated"
And there can also be man in the middle attacks or whatever, the efforts you do for validation depends still on your task at hand. How critical an error would be.
But even for the most trivial tasks I would never think of passing some user strings to Date and expect to get a valid value.
And there can also be man in the middle attacks or whatever, the efforts you do for validation depends still on your task at hand. How critical an error would be.
But even for the most trivial tasks I would never think of passing some user strings to Date and expect to get a valid value.
Good luck with a random dependency or dependency of a dependency that doesn’t work that way.
Lots of surprises here! The general theme seems to be that the parser is very eager to find some interpretation of the input as a date, even in ways that appear pretty unprincipled, even in circumstances where human users would probably not agree with the interpretation, and even though it does have ways that it could signal errors. Though maybe some of the weird cases actually do trace back to unusual real-world use cases!
The problem is that you couldn’t start to guess all of these. It’s just random noise. Strings 32-49 are in the 2000s but 50 onwards are in the 1900.
Burn it and start again.
Burn it and start again.
> Burn it and start again
Good news! The builtin Temporal API is on its way. It's widely regarded as a solid API, learning from some of the best time APIs in other languages.
In terms of parsing, it looks like Temporal only accepts RFC 9557 strings (an extension of ISO 8601 / RFC 3339). Anything else throws an exception.
Good news! The builtin Temporal API is on its way. It's widely regarded as a solid API, learning from some of the best time APIs in other languages.
In terms of parsing, it looks like Temporal only accepts RFC 9557 strings (an extension of ISO 8601 / RFC 3339). Anything else throws an exception.
Bad news: shitty designed parts are here to stay, because people will cry for backwards compatibility.
Sure. But people don't have to keep using them.
Of course... they will. Because there are going to be more outdated results on search engines for Date, instead of the Temporal API. But at least there's something positive coming!
Of course... they will. Because there are going to be more outdated results on search engines for Date, instead of the Temporal API. But at least there's something positive coming!
As is usual with these JS critiques, the problem is that you'd never do most of this. Yes, it's silly, but nobody passes random strings into the date constructor because all you really need to know is that the date constructor does weird shit with random strings.
You don't need to burn it, you just need to never rely on the constructor for parsing user input. It all works fine as long as you know the structure of the data before you pass it in.
You don't need to burn it, you just need to never rely on the constructor for parsing user input. It all works fine as long as you know the structure of the data before you pass it in.
Those are both big qualifiers...
1. Know not to use the constructor.
2. Make assumptions about user input.
Neither seem awesome.
Neither seem awesome.
Hopefully this quiz helps with the first point :)
I don’t think this is a very good defence.
Let’s say you started a date lib right now that would take random strings and do its best.
Suppose you identify the string is only integers. What logic needs to be applied to make the example I pointed out make any sort of common sense?
Let’s say you started a date lib right now that would take random strings and do its best.
Suppose you identify the string is only integers. What logic needs to be applied to make the example I pointed out make any sort of common sense?
>Let’s say you started a date lib right now that would take random strings and do its best.
why would you do that? that's a bad idea, and no matter what implementation you choose you will end up with some silly compromises like javascript has in it's date constructor. javascript's default choices are probably no better or worse than whatever choices you would make.
if you're writing a date parser, the first thing you should do is come up with a better definition than "take random strings and do your best" unless you're putting an LLM behind it.
why would you do that? that's a bad idea, and no matter what implementation you choose you will end up with some silly compromises like javascript has in it's date constructor. javascript's default choices are probably no better or worse than whatever choices you would make.
if you're writing a date parser, the first thing you should do is come up with a better definition than "take random strings and do your best" unless you're putting an LLM behind it.
> you just need to never rely on the constructor for parsing user input.
A rather large disadvantage in a programming language for developing user interfaces
A rather large disadvantage in a programming language for developing user interfaces
[deleted]
I can sympathise with the urge to write code that produces a valid answer if at all possible.
Usually I can overcome that urge. It's curious that these designers could not.
Usually I can overcome that urge. It's curious that these designers could not.
Yeah this is the curse of the intermediate developer at work
The junior developer experiences nothing but errors, and struggles to get something over the line
The intermediate developer adopts “reduce errors at all cost” mentality and their parsers are too helpful, they make too many assumptions, and you end up with the Date class type behaviour.
The senior developer knows the deadliness of this, and designs a robust class that behaves consistently and errors early on invalid input.
The junior developer experiences nothing but errors, and struggles to get something over the line
The intermediate developer adopts “reduce errors at all cost” mentality and their parsers are too helpful, they make too many assumptions, and you end up with the Date class type behaviour.
The senior developer knows the deadliness of this, and designs a robust class that behaves consistently and errors early on invalid input.
Scored 17/28. Thank you, this is absolutely cursed! It's probably a good time to go and check out the Temporal stuff (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...).
They're certainly taking their sweet time with it. Reading the last progress update is mildly entertaining though: https://github.com/tc39/notes/blob/HEAD/meetings/2024-07/jul...
That's not the last progress update. Most recent is https://github.com/tc39/notes/blob/d5b5db6969359fad11b6898b7....
Implementations are ongoing and open source, so you can contribute if you want it to come faster! V8 is currently aiming to use https://github.com/boa-dev/temporal IIRC.
Implementations are ongoing and open source, so you can contribute if you want it to come faster! V8 is currently aiming to use https://github.com/boa-dev/temporal IIRC.
Ha-ha, thanks, I couldn't help but chuckle a bit at that intro. As for them taking their time... Well, yes, it's all rather sad, but I personally came to terms long ago with the snail's pace of JS proposals rolling out. And after all, working with dates and time zones is a rather complex matter in itself, so no judgment here.
I've had to develop interfaces built entirely around date and time operations, and it was painful not so much because of the awful and broken date parsing in JS (although it definitely doesn't help), but rather because of the inherent complexity of how we represent calendar dates and times, and how we build abstractions around these representations. Definitely NOT looking forward to developing that booking system at work...
I've had to develop interfaces built entirely around date and time operations, and it was painful not so much because of the awful and broken date parsing in JS (although it definitely doesn't help), but rather because of the inherent complexity of how we represent calendar dates and times, and how we build abstractions around these representations. Definitely NOT looking forward to developing that booking system at work...
10/28. Not bad. But probably also is implementation dependent: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
I'm not sure if I should be pleased or embarrassed about my 17/28. Why do I even know this?
My son was pretty happy with his 11/28 without any experience with js Date. Just deduced it from previous answers. And I explained type coercion to him.
I now realize I may have put him off a career in IT.
My son was pretty happy with his 11/28 without any experience with js Date. Just deduced it from previous answers. And I explained type coercion to him.
I now realize I may have put him off a career in IT.
Javascript put me off a career in IT for 20 years, and even today I still avoid it like radioactive waste.
It very much is. I put the lil notice at the start that I verified the questions on a specific version of Node, with a specific timezone, because both things matter.
Some notes that I have noticed. First, why does it seem that the V8 date parser is heavily inspired by the Windows date parser (https://devblogs.microsoft.com/oldnewthing/20200304-00/?p=10...)? EDIT: Apparently not, "new Date('Savvyday 29 Oatmeal 94')" is invalid both in Firefox and Chrome.
Second, I opened this in Firefox with the console open to answer these questions, and found these divergences (to summarize, Firefox is strict):
Question 14:
Firefox returns an Invalid Date object instead.
Question 16:
Again, Firefox returns an Invalid Date object instead.
Question 19:
Seems a broken record, but this is still an Invalid Date for Firefox.
Question 20:
Ibid in Firefox.
Question 21:
No, Firefox is still not accepting this one.
Question 22:
Neither this one.
Question 23:
Firefox: Not really.
Final note: It parses Question 24 as you expect in Firefox. Which honestly, it shouldn't!
Second, I opened this in Firefox with the console open to answer these questions, and found these divergences (to summarize, Firefox is strict):
Question 14:
new Date("12.1")
Firefox returns an Invalid Date object instead.
Question 16:
new Date("12.-1")
Again, Firefox returns an Invalid Date object instead.
Question 19:
new Date("maybe 1")
Seems a broken record, but this is still an Invalid Date for Firefox.
Question 20:
new Date("fourth of may 2010")
Ibid in Firefox.
Question 21:
new Date("May 4 UTC")
No, Firefox is still not accepting this one.
Question 22:
new Date("May 4 UTC+1")
Neither this one.
Question 23:
new Date("May 4 UTC+1:59")
Firefox: Not really.
Final note: It parses Question 24 as you expect in Firefox. Which honestly, it shouldn't!
It's probably improved the past 8 years or so, but I remember Safari was particularly bad for bugs around DST and just dates in general back then, even when using valid input.
We ended up with a bunch of Safari specific workarounds that weren't necessary on Chrome (it was mostly a webview use case so Safari and Chrome were the two we cared about at the time)
Assumingly to me this was around the same time that Apple seemed to have DST problems more generally, such as their iOS alarm clock mishap https://www.theguardian.com/technology/blog/2010/nov/01/ipho...
We ended up with a bunch of Safari specific workarounds that weren't necessary on Chrome (it was mostly a webview use case so Safari and Chrome were the two we cared about at the time)
Assumingly to me this was around the same time that Apple seemed to have DST problems more generally, such as their iOS alarm clock mishap https://www.theguardian.com/technology/blog/2010/nov/01/ipho...
A quick test of Vivaldi with some of those shows it nowhere near as strict as your Firefox is. Amusingly
new Date("2025-07-12 12:30:45 BST")
new Date("2025-07-12 12:30:45 GMT")
new Date("2025-07-12 12:30:45 UTC")
new Date("2025-07-12 12:30:45 Z")
Yeah, as I understand it this isn’t backed by any spec. I decided to go with Node’s (v8’s) implementation for the quiz. Fun to see how much divergence there is!
At the beginning of the quiz, the author noted the exact time zone their laptop is in, have at least one of the questions I got wrong because I didn't take that into account. Totally valid though, and I honestly felt like I should have recognized that it would come into play given how I noticed how specific it was before starting
It’s a mean thing for me to have done, and I did originally have an extra little disclaimer on the questions where it was relevant, but I removed it because it felt like the shock value was more funny.
I think it was more than fair! The point to me of the quiz is how unexpected the behavior is in all of these cases, and the behavior being time-zone dependent is certainly part of that
I use iso strings for dates in JS, because they're such a trap. (As evidenced by even the first few quiz questions here). Moment, a popular alternative, is as bad in many ways. It conflates "date", "time", and "datetime", which causes so much trouble. The explanation I've heard is "time" and "date" shouldn't exist, which is, semantically, incompatible with my experiences.
Yeah a lot of these popular libraries - including Moment, Luxon, Day.js - commit the sin of using a single type of object for distinct concepts. Absolute time, civil time? Basically the same thing right? Just shoehorn them both in.
I can understand why JS' Date is the way it is, but Moment, and even more so Luxon and Day.js, have no excuses - Joda Time has been around since what, 2005?
Always fun to click through JS quizzes for the laughs. I've been programming JS since over a decade, and I never dared to use Date to parse anything I didn't verify with a regex.
so true.
i coded security js code for a decade. right when the standard started to get the many updates.
our system was just a really tiny subset of things you could use that worked safely (and predictably) across browsers. even after the updates, we only incorporated was array.filter and structuredcopy. everything else offered no real benefit and only added to the attack surface.
and then came typescript. the biggest missed opportunity in js history.
even today, good js is knowing you can only use 1% of the language, and even that with lot of care
i coded security js code for a decade. right when the standard started to get the many updates.
our system was just a really tiny subset of things you could use that worked safely (and predictably) across browsers. even after the updates, we only incorporated was array.filter and structuredcopy. everything else offered no real benefit and only added to the attack surface.
and then came typescript. the biggest missed opportunity in js history.
even today, good js is knowing you can only use 1% of the language, and even that with lot of care
And now you have two problems
Post by the author Sam Rose about it: https://bsky.app/profile/samwho.dev/post/3ltpdkr3bmk2o
It me.
Fix the font for the description field that appears after someone picks an answer. On a normal Windows 10 install, the 0 (zero) is rendered identically to a lowercase o.
If you're going to use fancy fonts at least make them webfonts.
If you're going to use fancy fonts at least make them webfonts.
This should be fixed.
I picked fonts that are present on a wide variety of systems without having to be downloaded on page load. I just forgot some CSS to make sure numbers looked distinct.
Fortunately someone sent me a PR with the right CSS.
I picked fonts that are present on a wide variety of systems without having to be downloaded on page load. I just forgot some CSS to make sure numbers looked distinct.
Fortunately someone sent me a PR with the right CSS.
4 / 28
"You would have scored higher by guessing at random."
I think my strategy for JavaScript going forward is to 'drop & run'.
I think my strategy for JavaScript going forward is to 'drop & run'.
If you guess at random, that's 25% probability to get the right answers, which gets you 7/28 points in average. I got 14/28 by trying hard and I still hate the result, but it's also true that the questions were largely impractical: noone parses dates like this in a real production app. We always validate the date format first. So noone should feel bad at their results.
Same here! Too bad... I did guess at random! :D
Anyway, after the experience trying to automate something with Google Sheets and wasting 4 hours just to discover that months start at 0 (in the context of parsing string dates and creating Date objects)... yep, no more JS for me.
Anyway, after the experience trying to automate something with Google Sheets and wasting 4 hours just to discover that months start at 0 (in the context of parsing string dates and creating Date objects)... yep, no more JS for me.
JavaScript’s Date class is a fairly straight port from Java, including most of the WAT in this quiz
https://docs.oracle.com/en/java/javase/21/docs/api/java.base...
yup. this goes together with the "0.1 + 0.2" outrage
So... any browser other than Firefox feel like shipping Temporal yet?
Deno supports it behind a flag[1]
Chrome is implementing it[2]
WebKit has an open PR[3]
I found no reference to Node working on it
and of course you can already use a polyfill (though it's quite heavy)
[1] https://deno.com/blog/v1.40?ref=computus.org#temporal-api
[2] https://chromestatus.com/feature/5668291307634688?ref=comput...
[3] https://github.com/WebKit/WebKit/pull/45603
Chrome is implementing it[2]
WebKit has an open PR[3]
I found no reference to Node working on it
and of course you can already use a polyfill (though it's quite heavy)
[1] https://deno.com/blog/v1.40?ref=computus.org#temporal-api
[2] https://chromestatus.com/feature/5668291307634688?ref=comput...
[3] https://github.com/WebKit/WebKit/pull/45603
12/28, could've gotten a few more by thinking harder, but I was getting so annoyed that I didn't want to, great job!
Cute. But things like these have tendency to be abused by “haha, js” crowd even if those things are irrelevant in practice.
Generally true, but the Date and everything around it being absolutely incomprehensible and totally bonkers is very relevant in practice. It's pain to use and triggers billions of bugs daily. It's not an abuse to point out even more wtf about it.
This matches my experience. This is a bit of fun but I’m hoping it has the positive side effect of making people more cautious about how they use Date.
I think it is relevant, it's a part of the standard library. It's one problem that JS has one of the smallest standard libraries, and it's another that the parts it does have just... don't work.
And, "don't use the standard library" is not a solution. Well I mean it is, but it's not free - there's caveats. Which tools do you choose? How do you make sure all your engineers use the same ones? How do you make sure nobody touches the standard library? It's not an easy problem.
And, "don't use the standard library" is not a solution. Well I mean it is, but it's not free - there's caveats. Which tools do you choose? How do you make sure all your engineers use the same ones? How do you make sure nobody touches the standard library? It's not an easy problem.
date.getYear() => 125
If that’s not relevant, I don’t know what is.
If that’s not relevant, I don’t know what is.
> date.getFullYear() => 2025
`getYear` is literally deprecated everywhere and is not part of the spec.
https://tc39.es/ecma262/multipage/numbers-and-dates.html#sec...
`getYear` is literally deprecated everywhere and is not part of the spec.
https://tc39.es/ecma262/multipage/numbers-and-dates.html#sec...
Right, but it exists and looks correct and runs and won’t trigger any kind of error if you write code that uses it.
This is what we call a ‘foot gun’.
This is what we call a ‘foot gun’.
On the other hand, you notice it the second you go use the software you just wrote to ensure it works.
So it’s more like a foot dollar store water gun.
So it’s more like a foot dollar store water gun.
No, it's a proper footgun, same as dereferencing a nullptr in C++. You'll notice that too - doesn't mean it's not a footgun.
And, in fact, most C++ compilers today will actually warn you when you derefernence a nullptr in a stupid, obvious way. Evidently, JS has not caught up to this incredibly sophisticated technology /s.
And, in fact, most C++ compilers today will actually warn you when you derefernence a nullptr in a stupid, obvious way. Evidently, JS has not caught up to this incredibly sophisticated technology /s.
JS has caught up - it has a sophisticated compilation and linting ecosystem called ‘TypeScript’.
Which at least will tell you you’re using a deprecated API, but won’t overcome the dumb API naming choices JavaScript blindly imported from Java
Which at least will tell you you’re using a deprecated API, but won’t overcome the dumb API naming choices JavaScript blindly imported from Java
We've come full circle. The build systems for JS, a scripting language, make C++ compilation look trivial. And, unfortunately, that's reflected in the compile times.
Today you should use getFullYear() => 2025
getYear() returns 125 as it was standard for dates to be offset from 1900 (which led to the Y2K problem). This behaviour should be maintained forever. "Nothing is more important than backwards compatibility"
Or rather, that should be mindset, so that we can achieve at least 90% backwards compatibility in practice.
getYear() returns 125 as it was standard for dates to be offset from 1900 (which led to the Y2K problem). This behaviour should be maintained forever. "Nothing is more important than backwards compatibility"
Or rather, that should be mindset, so that we can achieve at least 90% backwards compatibility in practice.
Yes, a language that was created in 1995 was entirely justified in adopting a convention that would break within five years.
Java 1.0 (also released in '95) had the same behaviour. Java itself borrowed it from `struct tm` in libc, which has the same behaviour from back then up until today. It was standard back then. Whether we like it or not (I don't) doesn't change that fact. And like I said, nothing is more important than backwards compatibility.
It is just programmer education to know to add 1900 to years when using struct tm and also to use getFullYear() in JS.
It is just programmer education to know to add 1900 to years when using struct tm and also to use getFullYear() in JS.
Why is nothing more important than backwards compatibility between disparate languages written in different contexts for different contexts?
That javascript chose to offset from 1900 was simply because every system back then used to, including Java.
Once that had been done, future versions of javascript had to maintain the same behaviour. This is where I'm using the backwards compatibility argument.
Once that had been done, future versions of javascript had to maintain the same behaviour. This is where I'm using the backwards compatibility argument.
Seems like JS could have called it `getYearOffset1900`, or `getYearOffet`, etc, rather than `getYear`.
Agreed. What I've read is that they basically duplicated the Java API, which had getYear()
I suppose the offset method was really quite entrenched so no one thought to special case that function, instead special casing the "2025" returning getFullYear()
I suppose the offset method was really quite entrenched so no one thought to special case that function, instead special casing the "2025" returning getFullYear()
9/28 - This was very good fun. Can't believe so much of the world's (important?) software is written in this toy language.
One thing I wonder is how could this have happened. It seems that this what a herd of absolute beginners would come up with: strong inconsistency and a bunch of heuristic that are not composable. But I imagine this was not the result of a bunch of beginners, what were the forces that lead to such a situation?
A couple of other comments have noted, and Brendan Eich himself actually replied on Twitter (https://x.com/brendaneich/status/1944156296212886005?s=46), to say that it was a copy of Java’s Date class behaviour. I haven’t dug into the history of that, though.
Thanks. More info in this thread:
https://x.com/BrendanEich/status/1752615257615528205
https://x.com/BrendanEich/status/1752615257615528205
To be somewhat fair, most of what this is poking fun at is the parsing of strings that do not remotely resemble actual dates. It's very edge case behaviour. Yes, it'd be nice if the edge cases did something more predictable, like all just fail with an error, but unless you're doing something silly like passing whatever a user writes straight into Date.parse() it isn't going to matter.
Realistically, you're going to use an actual date library, because even the good bits of Date are pretty bad.
Realistically, you're going to use an actual date library, because even the good bits of Date are pretty bad.
> parsing of strings that do not remotely resemble actual dates.
But this is somehow my point, what were the reasons that lead to parse those strings as dates. I guess the answer is usually legacy, but in that "legacy" why did someone need to take those decisions? My naive way of parsing dates would be to reject everything that doesn't have a well defined format while the format is well defined and at least somehow composable, but here someone had the need (I hope the had the need) to parse these seemingly random strings, I wonder why.
But this is somehow my point, what were the reasons that lead to parse those strings as dates. I guess the answer is usually legacy, but in that "legacy" why did someone need to take those decisions? My naive way of parsing dates would be to reject everything that doesn't have a well defined format while the format is well defined and at least somehow composable, but here someone had the need (I hope the had the need) to parse these seemingly random strings, I wonder why.
When a language allows operator overriding or doesn't have static typing, you can end up with situations like this where a single method does 10 different things for 10 different use-cases. Even Java and C++ aren't a stranger to APIs like this (although not nearly as bad).
I found that too painful to get further than #14
Cool.
The first set of questions are logical and make some sense. But then there come questions asking you similar but with slightly different values.
And that’s when everything stops making sense.
The first set of questions are logical and make some sense. But then there come questions asking you similar but with slightly different values.
And that’s when everything stops making sense.
The description field uses a typeface that obnoxiously renders 0 (zero) to look like^W^W (upon further investigation: be identical to) lowercase o...
At least on my pretty standard Windows 10 system. No idea which ones of the fonts Avenir, Montserrat, Corbel, URW Gothic, source-sans-pro, sans-serif is being used.
At least on my pretty standard Windows 10 system. No idea which ones of the fonts Avenir, Montserrat, Corbel, URW Gothic, source-sans-pro, sans-serif is being used.
This should be fixed. Sorry about that.
Another thing is with timezone: https://github.com/date-fns/tz/issues/57
I'm not sure if it's caused by JavaScript quirkiness under the hood or a bug in the library, but it's mindblowing.
I'm not sure if it's caused by JavaScript quirkiness under the hood or a bug in the library, but it's mindblowing.
Since the website says "All questions verified using NodeJS 24.4.0" and that all string parsing made by the Date constructor is define in ECMAScript to follow ISO 8601 plus being engine specific, the sub headline should say: How well do you know V8's Date parsing?
I bet you’re fun at socially coordinated gatherings of individuals convened for the explicit purpose of engaging in recreational, celebratory, or convivial activities, often characterized by the consumption of food and beverages, the enjoyment of music or other entertainments, and the collective participation in structured or unstructured merriment.
Well, because fun is an amorphous concept defined to be human-specific, your comment should say:
I am willing to (sarcastically) stake something of value on the premise that you are considered to be an interesting individual to interact with by your interlocutors and bystanders at socially coordinated gatherings of individuals convened for the explicit purpose of engaging in recreational, celebratory, or convivial activities, often characterized by the consumption of food and beverages, the enjoyment of music or other entertainments, and the collective participation in structured or unstructured merriment.
I am willing to (sarcastically) stake something of value on the premise that you are considered to be an interesting individual to interact with by your interlocutors and bystanders at socially coordinated gatherings of individuals convened for the explicit purpose of engaging in recreational, celebratory, or convivial activities, often characterized by the consumption of food and beverages, the enjoyment of music or other entertainments, and the collective participation in structured or unstructured merriment.
[deleted]
So what’s the consensus on the solution to this chaos? MomentJs? LuxonsJs? Temporal?
I just fixed a bug at work where JS Date was parsing arbitrarily long strings as random date values just because they happened to contain an integer anywhere in the string. Madness.
I'm curious how would a formal spec define those behaviors.
IIRC it was basically undefined, some data formats were defined. Eventually it was specified that it must correctly parse RFC 3339 and everything was browser defined. I think in the name of web compatibility they have started to carefully define the legacy behaviours of common browsers.
But the morale of this story should be if you need a date from a user user a date input and if you need to parse a computer-readable date always use UNIX timestamps or RFC 3339 (which are correctly and consistently supported).
But the morale of this story should be if you need a date from a user user a date input and if you need to parse a computer-readable date always use UNIX timestamps or RFC 3339 (which are correctly and consistently supported).
It's one of the [incorrect] answers to these questions: "Throws an error".
What I have learned is that "new Date(...)" never throws errors, and you would have to do something like "new Date(...).toISOString()".
This is one of the reasons that I, an amateur dev, never touch dates other than via date-fns or other date libs.
Dates and times are insane, no matter the language.
Dates and times are insane, no matter the language.
Lots of lessons in language design here. No explicit error return type and null bottom type create high ambiguity in such edge cases.
And don’t forget that Date objects are mutable!
Any explanation for ignoring parenthetical text? Is this maybe indirectly inherited from RFC 822?
personal take: store dates as bigints. rendering them is just a user interface issue. no need for Date parsing except to play nicely with legacy codebases. Milliseconds are your friend
someone should make one for Python based on https://github.com/satwikkansal/wtfpython
My firefox JS console has different answers to this quiz.
28 reasons to not use the built-in Date class
JavaScript has survived because it must be backwards compatible, not because it ever made sense.
Adding Temporal will only add to the chaos. Now there will be Date, moment, Luxon’s objects, and Temporal. See??? We fixed it!!!
Adding Temporal will only add to the chaos. Now there will be Date, moment, Luxon’s objects, and Temporal. See??? We fixed it!!!
Temporal is the language's attempt to fix the issues, instead of relying on 3rd party tools. The current situation forces developers to either choose something supported by the language, which has certain guarantees for backwards compatibility but is awful, and a 3rd party tool, which does not and is not as bad. It seems like the logical resolution is for the language to step up its game, since 3rd party tools have no obligation to be maintained or backwards compatible, or even to remain popular.
Too many standards? Time to add another one. This one will be final, I promise.
See also: "Falsehoods programmers believe about time and time zones":
https://news.ycombinator.com/item?id=11515125
https://news.ycombinator.com/item?id=11515125
JavaScript is hilarious through and through.
Haha that was fun :D
Thanks!
Thanks!
Why?
I discovered the 0/“0” disparity in work this week for the first time. Then I tried “1” and “2” and knew there was fun to be had. :)
But who came up with such a confusing „logic“?
„0“ and „1“ are for years, everything above are month.
Does the text parsing only work for English or other languages too?
„0“ and „1“ are for years, everything above are month.
Does the text parsing only work for English or other languages too?
I got 11/28, feeling pretty proud of myself honestly
10 / 28 lol, that's sad
In a language which doesn't understand that "false" isn't true? I would be entirely unsurprised to discover it's secretly calling a browser vendor web API to search for similarly named dates, or that it's now AI powered and might decide "Last Christmas" means the release date (December 3 1984) of the single not like, Christmas Day in 2024...
I think after the 1970s "Worse is better" languages vanish from the Earth the last shadow of that thinking left might be Javascript, hopefully by then humans aren't writing it but of course for "compatibility" it'll still be implemented by web browsers.
I think after the 1970s "Worse is better" languages vanish from the Earth the last shadow of that thinking left might be Javascript, hopefully by then humans aren't writing it but of course for "compatibility" it'll still be implemented by web browsers.
Why wouldn’t “false” be true? It’s a non-empty string.
For the same reason dogs aren't the square root of two and justice isn't golf? They're not the same kind of thing at all, if you insist that we should be able to compare them then they're not equal, and since programmers are human and make mistakes probably comparing them is itself a mistake.
You've completely disregarded type system rules of the language, and continue doubling down on your ignorance with ridiculous examples.
> They're not the same kind of thing at all, if you insist that we should be able to compare them then they're not equal, and since programmers are human and make mistakes probably comparing them is itself a mistake.
It is literally encoded in the spec.
https://262.ecma-international.org/13.0/#sec-toboolean
> They're not the same kind of thing at all, if you insist that we should be able to compare them then they're not equal, and since programmers are human and make mistakes probably comparing them is itself a mistake.
It is literally encoded in the spec.
https://262.ecma-international.org/13.0/#sec-toboolean
This reasoning is essentially circular.
You're saying that the design makes sense because there's a definition, and the definition is what makes it make sense.
There is value in having defined behaviors, but those behaviors can't be immune from criticism. That's letting the tail wag the dog. The purpose of a program is not to execute the rules of the programming language. It's to perform a real and useful task. If those real and useful tasks are complicated because synthetic and arbitrary behaviors of the language exist, then the language is wrong. The tool exists to do work. The work does not exist to provide academic examples for the language.
And, yes, it's possible for it to be impossible to determine a reasonable behavior, but that still doesn't mean we can't have reasonable behavior whenever possible.
You're saying that the design makes sense because there's a definition, and the definition is what makes it make sense.
There is value in having defined behaviors, but those behaviors can't be immune from criticism. That's letting the tail wag the dog. The purpose of a program is not to execute the rules of the programming language. It's to perform a real and useful task. If those real and useful tasks are complicated because synthetic and arbitrary behaviors of the language exist, then the language is wrong. The tool exists to do work. The work does not exist to provide academic examples for the language.
And, yes, it's possible for it to be impossible to determine a reasonable behavior, but that still doesn't mean we can't have reasonable behavior whenever possible.
> The purpose of a program is not to execute the rules of the programming language. It's to perform a real and useful task. If those real and useful tasks are complicated because synthetic and arbitrary behaviors of the language exist, then the language is wrong. The tool exists to do work. The work does not exist to provide academic examples for the language.
The tasks are not complicated because of this, it literally is default behavior in mainstream languages. And no, they’re neither synthetic, nor arbitrary limitations. The rule is based on types, not on whatever one specific value might mean.
And if they were to define “exceptions”, where do you draw the line?
“F41S3” is this? False? No? What if I’m a l33t h4x0r? What about 0xF4153? Looks false enough to me.
The tasks are not complicated because of this, it literally is default behavior in mainstream languages. And no, they’re neither synthetic, nor arbitrary limitations. The rule is based on types, not on whatever one specific value might mean.
And if they were to define “exceptions”, where do you draw the line?
“F41S3” is this? False? No? What if I’m a l33t h4x0r? What about 0xF4153? Looks false enough to me.
Again, you are explaining the specifications to defend why the specifications are what they are. That's circular reasoning. Describing the behavior doesn't defend it, and invoking convention doesn't work because different languages have different conventions (which is how we got here).
You know what you do when you can't handle an exceptional case? You throw an exception! Emitting errors is not undesirable behavior! It just means the computer says, "I don't know what to do so I better stop." You're never going to design all possible exceptions away, and that's not a flaw.
The question you should be asking is: why does it ever make sense to silently compare a character string to anything other than a character string? Semanticly, it's nonsense to compare different types. The only way you can do it is when the other type has a canonical string representation, neverminding issues of culture or language.
This is why, for example, C# has String.IsNullOrWhitespace() and String.IsNullOrEmpty(). It's partly to cover common combinations, but also to idiomatically determine if a meaningful value is present, which is what `StringVal == True` and `if (StringVal)` are trying to express and failing at.
You know what you do when you can't handle an exceptional case? You throw an exception! Emitting errors is not undesirable behavior! It just means the computer says, "I don't know what to do so I better stop." You're never going to design all possible exceptions away, and that's not a flaw.
The question you should be asking is: why does it ever make sense to silently compare a character string to anything other than a character string? Semanticly, it's nonsense to compare different types. The only way you can do it is when the other type has a canonical string representation, neverminding issues of culture or language.
This is why, for example, C# has String.IsNullOrWhitespace() and String.IsNullOrEmpty(). It's partly to cover common combinations, but also to idiomatically determine if a meaningful value is present, which is what `StringVal == True` and `if (StringVal)` are trying to express and failing at.
> The question you should be asking is: why does it ever make sense to silently compare a character string to anything other than a character string?
Because this is how C does it.
Because this is how C does it.
Certainly "this is how C does it" might be the worst possible rationale for anything in this space. And I like C, got paid a whole lot of money to write C over many years.
But hilariously it's not even true, you see C believes the empty string is also true, it's a string, only the absence of a string would be false in C - whereas Javascript is quite sure the empty string, just like an undefined or null value, is false.
But hilariously it's not even true, you see C believes the empty string is also true, it's a string, only the absence of a string would be false in C - whereas Javascript is quite sure the empty string, just like an undefined or null value, is false.
He's not disregarding the type system rules - everyone knows that JS has a "coerce everything" attitude to types. He's saying it's stupid, and I agree. That was a mistake.
But it shouldn’t be
So what should be the value of `"false" == true`?
undefined or TypeError would be suitable.
So shall we require checking for matching type of first? It doesn't seem like an improvement to me.
Should a list ever equal seven? Should a float equal a socket? Some comparisons just don't make sense.
> Should a list ever equal seven? Should a float equal a socket?
No.
> Some comparisons just don't make sense.
The comparison makes enough sense to me to determine the result.
No.
> Some comparisons just don't make sense.
The comparison makes enough sense to me to determine the result.
Even if the result makes some kind of sense, 99% of the time it will be an error in programming and therefore not be useful or safe to continue.
Should "falsch", "faux" and "ЛОЖЬ" be understood as false too?
Not at all, "false" shouldn't be false either, the appropriate thing to do when the programmer writes nonsense is to reject what they wrote entirely.
What a conventional wisdom for 30 year old language that is based on whatever state of the art was at the time.
They should’ve just deprecated it right away, invent Time Machine, move to the future, grab Rust and make it the scripting language. Duh.
They should’ve just deprecated it right away, invent Time Machine, move to the future, grab Rust and make it the scripting language. Duh.
You don‘t think being able to check the truthiness of strings is a useful thing?
A little bit of truthiness seems like a good idea at first. You decide to treat empty strings and undefined as falsy and it feels good, so you go ahead and start treating zero as falsy too.
And then all of a sudden code that is expecting to get an array or undefined gets handed a zero or an empty string because someone called it with
And then all of a sudden code that is expecting to get an array or undefined gets handed a zero or an empty string because someone called it with
x && [x]
x.length && x
What does "useful" mean here? Useful the way it'd be useful if butter knives could also cut trees down more easily or if hats were also televisions - ie more uses = more useful?
Programming languages aren't for the machine, they're for humans, and humans make mistakes so we need to design the language with that in mind. "Truthiness" is a footgun, it increases the chance you'll write something you did not mean without even realising.
Programming languages aren't for the machine, they're for humans, and humans make mistakes so we need to design the language with that in mind. "Truthiness" is a footgun, it increases the chance you'll write something you did not mean without even realising.
yea that's an odd example to pick. expecting type conversion to add meaning to strings is a programmer problem not a language problem. really comes down to developers not thinking about types and their meaning anymore.
there are plenty of javascript examples that are actually weird though, especiall when javascript DOES apply meaning to strings, e.g. when attempting implicit integer parsing.
there are plenty of javascript examples that are actually weird though, especiall when javascript DOES apply meaning to strings, e.g. when attempting implicit integer parsing.
It’s the _existence_ of an implicit conversion from string to boolean that the parent is pointing out as a problem, not how it’s implemented. But that’s Jãvascript bb
Maybe I’m missing the example but can you not check the truthiness of strings in basically any high level language? At least python does it the same way and it’s very useful.
neither Java nor .Net have implicit string to boolean conversions, the only way to asses the truthiness of a string is an explicit conversion - there’s no “if(someStringVariable)” - that’s just a type error at compile time.
edit: I'm mostly wrong here.
Because "0" is false. In a logical world, a non-empty string being truthy is fine even if the value is "false". Javascript isn't logical.
Because "0" is false. In a logical world, a non-empty string being truthy is fine even if the value is "false". Javascript isn't logical.
```
> if ("0") console.log("true");
true ```
Excuse me?
> In a logical world, a non-empty string being truthy is fine even if the value is "false". Javascript isn't logical.
You must hate our illogical world built on C, because it has the same behavior.
true ```
Excuse me?
> In a logical world, a non-empty string being truthy is fine even if the value is "false". Javascript isn't logical.
You must hate our illogical world built on C, because it has the same behavior.
Appealing to C - the land of undefined behavior - as a paragon of logic seems like a strange authority to reach for.
The point is that this is a well-defined (not pun intended) behavior that exists within C, C++, Python, Ruby and probably a handful more popular languages. This set pretty much constitutes like 70%(?) of mainstream languages. Yet only JS gets shit thrown its way in this thread.
I did a `"0" == false` which returned true. I may need another cup of coffee before making claims.
Are you crazy? Which language does? I can only think of markup languages that do.
Should "0" also === 0? How about "{}" === {}? When does it stop?
Should "0" also === 0? How about "{}" === {}? When does it stop?
What do you mean? false isn’t true in JavaScript.
“false”, not false. So there’s odd type coercion, but the problem is that it can happen without you asking for it.
Python does the same thing. I don’t like it there either, but at least it’s more consistent about it.
Python does the same thing. I don’t like it there either, but at least it’s more consistent about it.
The string with the value of "false" evaluates to true.
In other words
If ("false") { /* You will be here */ }
In other words
If ("false") { /* You will be here */ }