I worked in a team of four between 2017 and 2020 this way. I really enjoyed it. After that I joined a company that worked with PRs. Felt like such a waste of time.
IMO it's maybe the best suited language to AoC.
You can write it even faster than Python, has a very terse syntax and great numerical performance for the few challenges where that matters.
I know this is pretty personal but Python's way with indention really does not play well with throwing things out. It's obviously matter of practice, but languages that have same qualities but are easier on formatting issues and aren't that set on one correct way of writing things allow much doing things much faster. But at the end, it's personal :-)
Browsers can handle conversions just fine but they need some context. If that context is somehow tampered with, then the results might be weird.
In this case, SpaceX seems to be using UNIX timestamps(1) which is probably fed to a combination of Date and Intl to obtain a localized date string. Extrapolating the country where the user is located is not really rocket science either. But, if my context is somehow tampered with (VPN, internal clock, browser settings…), then I will get a potentially "wrong" date, for whatever definition of "wrong".
The problem is fundamentally the same on the server side because you can only rely on the information you get… which might be wrong.
So either you take the safest route, which is to display the local time of the organization or its UTC representation and let visitors figure out their local date on their own, or you take a somewhat riskier one, which is to try to display a localized date to your users and accept the potential flaws of the method.
Yes, by setting the datetime attribute (in UTC) on a time element, then on the client side pulling that into a Date object and calling toLocaleString().
I do end up changing apartments after the two year lease period because I get bored of the area or the landlord raises the rent.