javascriptweb-applicationstimezonedjango-timezone

Formatting timestamps on the frontend


As has been asked in many other questions, how can I make e.g. Django admin portal use my browser's current time zone?

The usual way to solve that is to get the server to guess the time zone the client wants (potentially storing time zone preferences in the database etc.) and serve accordingly. However, nowhere do I see suggestions to use client-side JavaScript to convert timestamps.

To me it looks like the perfect solution, as JavaScript doesn't need to guess, and the server doesn't need to concern itself with effectively visual preferences of clients. Given that this is not the default approach, I assume there's some huge flaw I'm missing.

Why is JavaScript not typically used to convert timestamps in applications like Django admin portal?


Solution

  • This answer is not specific to Django or any technology used.


    As has been asked in many other questions, how can I make e.g. Django admin portal use my browser's current time zone?

    In general, you have to pass the current timezone to the backend in some way if you want to process timestamps (meaning: create formatted output) in the backend. If there's no way for you to pass that information to the backend inside the initial request, you have to store the information in a way the backend can access it, which usually means to store the infos in a database (but not necessarily, it could also be stored otherwise).

    The usual way to solve that is to get the server to guess the time zone the client wants (potentially storing time zone preferences in the database etc.) and serve accordingly.

    Yes, exactly (with the exception that it's not guessing when you know the preferences).

    However, nowhere do I see suggestions to use client-side JavaScript to convert timestamps.

    To me it looks like the perfect solution, as JavaScript doesn't need to guess, and the server doesn't need to concern itself with effectively visual preferences of clients. Given that this is not the default approach, I assume there's some huge flaw I'm missing.

    I understand that as "let JavaScript decide how to format the timestamp without passing in specific formatting rules".

    What comes to mind is that you don't necessarily use a computer in the country/timezone you usually use it in. Imagine you sit in front of a computer in the US while you live in Germany. In that case, you'd prefer to see dates formatted according to german formatting rules and not US formatting rules. Even if it's your own computer (maybe you are just on vacation, who knows?), it is likely that you change the clock (and timezone) while being abroad and still want to see dates being formatted the way you are used to. Meaning that:

    new Date(TIMESTAMP).toLocaleString()
    

    does not work, because it uses the host's locale. Instead, you'd have to pass in further formatting information:

    new Date(TIMESTAMP).toLocaleString(LOCALE)
    

    Where does that LOCALE information come from? You have to store it somewhere.

    This boils down to: Regardless of which technology you use to format timestamps, you still have to have the user's preferences stored (except if you do not care about them - but then this whole question is nonsense). This means it does not matter if you format on the front- or backend, you do not have to "guess" and you likewise cannot let the host "decide" or you very likely did something wrong.

    Why is JavaScript not typically used to convert timestamps in applications like Django admin portal?

    Because Django runs with Python.