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.
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.
[1] https://sxcontent9668.azureedge.us/cms-assets/future_mission...