Localize dates and times #590
Conversation
By formatting datetime on the server, we get nice localized datetime strings that are adapted to the currently-selected language. Example: - English: "Apr 26, 2020, 3:58:54 PM" - French: "26 avr. 2020 à 15:58:54" - German: "26.04.2020, 15:58:54" - Spanish: "26 abr. 2020 15:58:54" - Indonesian: "26 Apr 2020 15.58.54" - Chinese: "2020年4月26日 下午3:58:54" However, there is a downside: time is not adapted to the user timezone. The solution is to define a timezone on the server: we use the server OS timezone by default, and it can be customized through the BABEL_DEFAULT_TIMEZONE setting. It's still not ideal, because it assumes that all users are in the same timezone (the one configured on the server).
|
The more I think about this, the more I think that we should handle this kind of things on the client side, because on the server side, we have no idea what the locale of the user should be… |
|
@indatwood commented on 30 avr. 2020 à 18:27 UTC+2:
You mean the timezone? Because |
|
Sorry, I missed you question @Glandos ! My mind isn't fresh anymore about the topic, but I kinda remember that on the server side we cannot be sure to output the correct timezone information because it's not what's sent by the User-Agent. So, that's was the reason behind my comment at that time. But I believe that anyway, this patch provides some enhancements, and that we should merge it anyway. It will always be time to go back to this if we feel it's needed. |
|
That being said, by reading the code it seems that the server will decide what the TZ should be, without having a look at Also, it's not clear that it's what will happen from reading the docs, and I believe we should make it clearer. As the system administrator reading these docs, I'm not confident that the locale will be derived from the User-Agent. I might add a big thanks for doing this :-) |
|
Formatting date/time is always tricky on the web. Not really for technical reasons (see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/getTimezoneOffset), but because it's difficult to know if the user prefers to display time in its own timezone, or from the server timezone. If it's on the user preference, we could have a user setting, or use JavaScript. I don't really know what's best, but at least we will have one possibility here. So to me, we're good to go. @zorun Have you been using this patch in production? |
|
I believe I already answered the question of which timezone is selected by default, in the documentation patch: it's the timezone of the server OS. See also http://babel.pocoo.org/en/latest/dates.html#time-zone-support Reading the patch again, I think it's OK to be merged even if it's not perfect:
Of course, it would be better to adapt to the user timezone, but it would be much more work. It does not seem worth the effort just to display a time in the history page. |
|
Alright, let's stop trying to be perfect, we are not building a rocket full of uranium :) |
|
Happy with this :-) Thanks for the work. I agree with you on this, let's try to ship more and worry less about being perfect ;-) Cheers! |
See individual commits for details.
I'm not sure about this one. On the one hand, having localized date and time that follows the selected language is nice. On the other hand, the timezone issue (see 812efad) means that it would make more sense to format date and time in Javascript, but then we would have less control over the formatting and it won't follow the selected language.