The maintainer who this piece of “cursed knowledge” is referencing is a member of TC39, and has fought and died on many hills in many popular JavaScript projects, consistently providing some of the worst takes on JavaScript and software development imaginable. For this specific polyfill controversy, some people alleged a pecuniary motivation, I think maybe related to GitHub sponsors or Tidelift, but I never verified that claim, and given how little these sources pay I’m more inclined to believe he just really believes in backwards compatibility. I dare not speak his name, lest I incur the wrath of various influential JavaScript figures who are friends with him, and possibly keep him around like that guy who was trained wrong as a joke in Kung Pow: Enter the Fist. In 2025, I’ve moderated my opinion of him; he does do important maintenance work, and it’s nice to have someone who seems to be consistently wrong in the community, I guess.

It does raise the idea of managed backward compatibility.

Especially if you could control at install time just how far back to go, that might be interesting.

Also an immediately ridiculous graph problem for all but trivial cases.

On the other hand, one particular app completely refuses to allow users to remove location information from their photos: https://support.google.com/photos/answer/6153599?hl=en&co=GE...

I have no idea what that means but to me it looks like it works as designed.

A ward even

It's probably a clout thing, or just a weird guy (Hanlon's Razor), but a particularly paranoid interpretation is that this person is setting up for a massive, multi-pronged software supplychain attack.

The author is almost certainly ljharb.

I'm convinced he's a rage baiting account. No-one can consistently have such bad takes.

Not only is YYYY/MM/DD unambiguous, but it also sorts correctly by date when you perform a naive alphabetical sort.

I like CCYY-MM-DD because it's also a valid file name on most systems, and using "CCYY" (century + year) instead of "YYYY" feels fancy.

For a really cursed one that breaks your last comment, check out Kazakhstan on the list by country: https://en.wikipedia.org/wiki/List_of_date_formats_by_countr...

> Short format: (yyyy.dd.mm) in Kazakh[95][obsolete source]

in what world could mm/dd/yyyy not be cursed!? that makes no sense whatsoever.

It's the US short form, matching the word-month order we always use for regular dates: "August 7, 2025".

Note the slashes are important, we don't use dots or dashes with this order. That's what GP was getting at.

And it makes absolutely no sense. I've lived with it all my life (I'm an American!) and it has never made any sense to me.

First, I use ISO8601 for everything. This is not me arguing against it.

But, I think the American-style formatting is logical for everyday use. When you're discussing a date, and you're not a historian, the most common reason is that you're making plans with someone else or talking about an upcoming event. That means most dates you discuss on a daily basis will be in the next 12 months. So starting with the month says approximately when in the next year you're talking about, giving the day next says when in that month, and then tacking on the year confirms the common case that you mean the next occurrence of it.

When's Thanksgiving? November (what part of the year?) 27 (toward the end of that November), 2025 (this year).

It's like answering how many minutes are in a day: 1 thousand, 4 hundred, and 40. You could say 40, 400, and 1000, which is still correct, but everyone's going to look at you weirdly. Answer "2025 (yeah, obviously), the 27th (of this month?) of November (why didn't you start with that?)" is also correct, but it sounds odd.

So 11/27/2025 starts with the most useful information and works its way to the least, for the most common ways people discuss dates with others. I get it. It makes since.

But I'll still use ISO8601.

1 is only true by default, both HFS and APFS have case sensitive options . NTFS also behaves like you described, and I believe the distinction is that the filesystems are case-retentive, so this will work fine:

  $ echo yup > README.txt
  $ cat ReAdMe.TXT
  yup
  $ ls
  README.txt

Maybe the cursed version of the filesystem story is that goddamn Steam refuses to install on the case sensitive version of the filesystem, although Steam has a Linux version. Asshats

Datetimes in general have have a tendency to be cursed. Even when they work, something adjacent is going to blow up sooner or later. Especially if it relies on timezones or DST being in the value.

> 1. Filenames in MacOS are case-INsensitive, meaning file.txt and FILE.txt are equivalent

It's much more cursed than that: filenames may or may not be case-sensitive depending on the filesystem.

I'm in the process of writing up a blog post on how network shares on macOS are kind of cursed. Highlights:

* Files on SMB shares sometimes show up as "NDH6SA~M" or similar, even though that's not their filename on the actual network drive. This is because there's some character present in the filename that SMB can't work with. No errors or anything, you just have to know about it.

* SMB seems to copy accented characters in filenames as two Unicode code points, not one. Whereas native macOS filenames tend to use single Unicode code point accents.

* SMB seems to munge and un-munge certain special characters in filenames into placeholders, e.g. * <-> . But not always. Maybe this depends on the SMB version used?

* SMB (of a certain version?) stores symlinks as so-called "XSym" binary files, which automatically get converted back to native symlinks when copied from the network share. But if you try to rsync directly from the network drive instead of going through SMB, you'll end up with a bunch of binary XSym file that you can't really do anything with.

I only found out about these issues through integrity checks that showed supposedly missing files. Horrible!

Yep. Create a case-sensitive APFS or HFS+ volume for system or data, and it guarantees problems.

I created one of the first CDDBs in 1995 when Windows 95 was in beta. It came with a file, IIRC, cdplayer.ini, that contained all the track names you'd typed in from your CDs.

I put out requests across the Net, mostly Usenet at the time, and people sent me their track listings and I would put out a new file every day with the new additions.

Until I hit 64KB which is the max size of an .ini file under Windows, I guess. And that was the end of that project.

Another strategy is to pass your values as an array param (e.g., text[] or int[] etc) - PG is perfectly happy to handle those. Using ANY() is marginally slower than IN(), but you have a single param with many IDs inside it. Maybe their ORM didn’t support that.

> This is a cursed idea to begin with, so I can't fully blame PostgreSQL.

After going through the list, I was left with the impression that the "cursed" list doesn't really refers to gotchas per se but to lessons learned by the developers who committed them. Clearly a couple of lessons are incomplete or still in progress, though. This doesn't take away from their value of significance, but it helps frame the "curses" as persona observations in an engineering log instead of statements of fact.

> One of their line items complains about being unable to bind 65k PostgreSQL placeholders (the linked post calls them "parameters") in a single query.

I've actually encountered this one, it involved an ORM upserting lots of records, and how some tables had SQL array-of-T types, where each item being inserted consumes one bind placeholder.

That made it an intermittent/unreliable error, since even though two runs might try to touch the same number of rows and columns, you the number of bind-variables needed for the array stuff fluctuated.

Or people who try to send every filename on a system through xargs in a single command process invocation as arguments (argv) without NUL-terminated strings. Just hope there are no odd or corrupt filenames, and plenty of memory. Oopsie. find -print0 with parallel -0/xargs -0 are usually your friends.

Also, sed and grep without LC_ALL=C can result in the fun "invalid multibyte sequence".

I don’t think that makes intuitive sense. Whether I send 50k rows or 10x5k rows should make no difference to the database. But somehow it does. It’s especially annoying with PG, where you just cannot commit a whole lot of small values fast due to this weird limit.

that also popped out at me: binding that many parameters is cursed. You really gotta use COPY (in most cases).

I'll give you a real cursed Postgres one: prepared statement names are silently truncated to NAMEDATALEN-1. NAMEDATALEN is 64. This goes back to 2001...or rather, that's when NAMEDATALEN was increased in size from 32. The truncation behavior itself is older still. It's something ORMs need to know about it -- few humans are preparing statement names of sixty-plus characters.

I’ve done this with my main drive for the last ten or so years and run into not a single problem. I recommend it.

> few humans are preparing statement names of sixty-plus characters.

Java developers: hold my beer

Then you don't use Time Machine, Migration Assistant, cmake, or a host of other development and systems tools that don't work correctly on case-sense APFS volumes.

Sorry, but this is terrible advice unsuitable for all audiences. It might seem to work for now but it's walking in a minefield of nonstandard configuration that could bite anytime in the future.

https://forums.macrumors.com/threads/does-anyone-else-use-a-...

https://forums.macrumors.com/threads/heads-up-currently-impo...

https://apple.stackexchange.com/questions/474537/time-machin...

https://gitlab.kitware.com/cmake/cmake/-/issues/26333

Hey, if I don’t name this class AbstractBeanFactoryVisitorCommandPatternImplementorFactoryFactoryFactorySlapObserver how would you know what it does?

I did use Time Machine, but thankfully wised up and left for restic instead. Using Time Machine is worse advice than case insensitive filesystem if you ask me. Inscrutable logs and silent failures.

I’m sure there are those who found problems, but fact remains that in ten years I never have. What I have found is a lot of warnings against it by people who don’t use it themselves, like the person in the second link.

I recommend it, and the more people use it, the more people can help fix bugs they encounter (if any?) like in that last link you posted.

PS the Time Machine error in your third link is apparently about a CI source to a CS target. I hope it’s fair to say: don’t do that?