Very nice of them to have automatic time conversion to my local time when visiting the page. Something practically no one bothers to do. Alas it is in the middle of the night for us europeans.
>Very nice of them to have automatic time conversion to my local time when visiting the page.
F1 finally has a really nice system for showing time[0]. They show both the local time at the circuit and the local time wherever the user is. For years they showed only the track time, without even a hint about the timezone the track was in.
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().
F1 finally has a really nice system for showing time[0]. They show both the local time at the circuit and the local time wherever the user is. For years they showed only the track time, without even a hint about the timezone the track was in.
[0] https://www.formula1.com/en/racing/2025