Hi, > Are you saying date translation should only be done on the client ?
I’m saying that’s an option and possibly a better solution. If one goes in another timezone, one is more likely to change its computer timezone than go through every website and change the settings there. > Unlike in Django, which is happy to translate the date for you ? That’s inexact as Django doesn’t translate the date for you out of the box. Extract from the Django documentation: "The current time zone is the equivalent of the current locale for translations. However, there’s no equivalent of the Accept-Language HTTP header that Django could use to determine the user’s time zone automatically. Instead, Django provides time zone selection functions. Use them to build the time zone selection logic that makes sense for you." > More code duplication. Can you elaborate ? > Is there anything conceptually wrong with an API providing a translated date > according to request language ? Which ones of PT, MT, CT or ET are you going to choose for en-US ? > Marek Regards, Xavier Ordoquy, Linovia. -- You received this message because you are subscribed to the Google Groups "Django REST framework" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
