>The way these type checkers get fast is usually by not supporting the crazy rich reality of realworld python code.
Nah, that's just part of the parade of excuses that comes out any time existing software solutions get smoked by a newcomer in performance, or when existing software gets more slow and bloated.
I've actually sometimes seen this as an argument in favor of JITed languages like C# and Java, that you can take advantage of newer CPU features and instructions etc. without having to recompile. In practice languages that compile to native binaries still win at performance, but it was interesting to see it turned into a talking point.
It's also still missing proper garbage collection, meaning languages like C# have to include basically the entire runtime if you compile to WebAssembly. This is a major part of why Blazor apps in .NET 5 are ~2MB for a simple "Hello World" (closer to 8MB if you use the AOT compilation options in the .NET 6 preview).
>As with all things time, I'm no expert, and could be wrong about something. If you are, please correct me!
Easy example that I have to deal with semi-regularly since I live and work in Mountain Time: Arizona. Arizona is under Mountain Time, but does not observe Daylight Savings. So America/Phoenix would work fine (and America/Denver for the rest of the Mountain Time zone) but simply using MT would not.
To complicate matters even more is that the Navajo reservation (which is partially in Arizona) observes DST, but the Hopi Reservation (also in Arizona, but completely surrounded by the Navajo Reservation) does not.
.NET's DatetimeOffset class does this really well, and what's nice is you can access the local system's timezone database to convert it to whatever the local time was in that timezone for a given date (it's aware of when DST or timezone changes occured). I'm sure several other languages have similar tools too.
It doesn't solve every conceivable timezone issue, but it solves 99% of the problems most developers would have with it.