Maybe you’re in this situation:

• You have a website.
• It runs in Internet Explorer 11.
• More specifically, it can run in a Windows application like, oh let’s say, Epic Hyperspace, that uses the operating system’s scripting environment… meaning the Windows application will more-or-less fire up IE11.
• Even more specifically, that Windows application is running on Windows Server 2012 or Windows 8.1
• Your site uses the Intl API. Maybe you use it directly, or perhaps you use a date/time library that takes advantage of it, like luxon.
• One day sort of recently, a small subset of your users started reporting that your site is busted. If they’re able to see script errors, they might be something like TypeError: Intl is not available, which is strange, because Intl most definitely should be available (albeit in a limited form). Perhaps luxon DateTime instances are spitting out something like "Invalid DateTime", which is strange, because that’s never happened before. Or maybe date/time calculations that used to work just fine start returning null.

Here’s what’s happening

This was an issue introduced with a security patch for some versions of Windows. The Windows application is missing something in its manifest, and the application developer needs to fix it.

Specifically, in the manifest XML, in the assembly > compatibility > application block, add this:

<!-- Windows 8.1 -->
<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>

(Or whatever this document happens to tell you to do.)

Fire up the Windows application again, and that’ll remove the weird errors about Intl being not available.

Other things you can try

If you only have to detect the presence of Intl, but don’t actually need to use it, you can wrap that detection in a try-catch block. That’s what the angular project ended up doing. Their issue history is the only reason I could figure out what was going on at all, so I’m glad that’s out there.

The comment in Angular’s code implies that the issue with Intl only happens when you’re also providing a polyfill or overwriting the JavaScript global Map API, so maybe you can remove that or load it conditionally (IE11 has Map natively); however, that didn’t fix it for us.

It’s funny

In programming, one of the hardest things to learn is that it’s pretty much never the popular library or operating system’s fault that something unexpected is happening in your program. It’s easy to find yourself thinking, “this must be something wrong with Amazon Web Services” or “surely I’ve discovered a fresh bug in React” or “holy smokes, I’ve unearthed a flaw in Linux!”

You are most likely wrong.

If I had to ballpark, I’d say that in this decade I’ve dealt with about 3,000 bugs or odd behaviors. 2,990 of them ended up being my own dang fault.

Maybe 9 were honest-to-god bugs that I found in broadly-used libraries, and most of those had already been discovered and patched by the time I “found” them.

And now this one, which was something going on deep in the interactions between the operating system and a third-party application. And it wasn’t my fault!

Yeah, once a decade for one of those sounds about right.