[Enhancement] International Datetime Format VS US Datetime Format problem and proposed solution: Let the User decide #2123
Replies: 9 comments
-
|
ISO 8601 based dates and times or bust, I say. |
Beta Was this translation helpful? Give feedback.
-
|
I'm a fan of bog-standard YYYY-MM-DD HH:MM:SS, personally. I like @luchaos's idea of leveraging Carbon datetime extension on #704, it can take a time zone string that could be pulled from the client using |
Beta Was this translation helpful? Give feedback.
-
|
Timezone is another matter... better to focus on Datetime Format only. |
Beta Was this translation helpful? Give feedback.
-
|
It is only my contributions being named in the OP and getting thumbs-down emojis on them, so I feel compelled to respond. The intention behind my contributions has always been to enhance the user experience for all users, regardless of their geographic location. I apologize if my work has made anyone feel that I am trying to proliferate one specific culture onto RA, as that is certainly not what I'm trying to do here. The reason the format has been changing is because I've been rewriting the components to use Laravel instead of legacy PHP, which often necessitates switching date parsing and rendering to use the Your suggestion to implement a customizable datetime format option is insightful. Our goal, as referenced in #704, is to make RAWeb accessible and user-friendly for a global audience. |
Beta Was this translation helpful? Give feedback.
-
I disagree on "regardless of their geographic location" part. Mostly of new contributions made recently or updated ones, have their Datetime Format changed without any valid reason to do so. I am NOT saying that those contributions were useless or it was better to let the RAWeb away with obsolete features. The main question here was: Why the Datetime Format was changed with absolutely no reason? Those changes from 24-hour DM to 12-hour MD time format weren't supposed to occur. Even a fix (#1969) was made to address the issue on exhibition of 0:37pm to 12:37pm on Active Players feed on Start Page some time ago (wasn't supposed to be AM instead of PM on that post, anyway?). They should had remained on International format as default as it was. If the International Datetime Format sounds not appropriated. Then, it's better to use
It's not a customizable thing. The idea of letting the user choose between International and US comes with the intention of pleasing both sides of the coin since: While I and some people might prefer International, some users might prefer it to be US based only. We are talking about 2 great majority sides of people and just asking everything to be International format OR just letting it to be changed to US format would be something unfair. We are on International community, that's why I suggested that option being FALSE as default. On worst case scenario, if this gets impossible to properly solve now, then, the ISO 8601 format is welcome. As I said, Datetime Format was and still a chaos on Website. For example, Set Ranking still uses ISO 8601, Audit Logs uses 24-hour DM, Recent Players uses 12-hour MD and so... Inbox/Outbox times were showing dates like we were in 1900 before. On Forum, the Month is fully mentioned instead of only 3 letters as expected. Another idea by my suggestion is act as a standardization of this issue too since is the User that will make a decision that would change every spot of the website that uses timestamps that can be automated, mitigating this chaos. I was planning to talk about this subject months ago because we already had this issue before RAWeb V5.0, but hadn't time to proper write it down. However, following the recent implementation of 12-hour MD format on Achievement Unlock timestamp, I feel compelled to take an action since this is becoming even worse than it was: Before, just the Main Graph (Users online) on Start Page was on 12-hour MD format. Now, it's almost everything.
My intention pointing the Datetime Format issue wasn't to target anyone. I mentioned the ones that I could remember and yours weren't the exclusive ones to change the datetime format. That Private Messages update changed it also. It's better understandable now the change following the Carbon explanation saw on your updated post, but this is still an issue which needs to be solved. (We don't use AM/PM here and neither 12-hour Month-Day format in Brazil...) |
Beta Was this translation helpful? Give feedback.
-
wes directly stated that this change will facilitate your request. The format change as it is sounds like a general side-effect of the update to Laravel/Carbon. I am sure once everything is converted then proper features for date time that benefit all users will be worked upon (it'd be bad to try to work on them when things are still a hybrid, IMO, since then somethings would follow the setting and others would not) |
Beta Was this translation helpful? Give feedback.
-
Adding support for improved l10n and i18n, as well as user settings to manage them, is on our roadmap which should address this. |
Beta Was this translation helpful? Give feedback.
-
|
We've begun adding l10n utils for date and number formats in #2706 (comment). |
Beta Was this translation helpful? Give feedback.
-
Now, it's time to talk about something present more aggressively since when RAWeb V5.0 came to light. This was present on several Pull Requests recently and on older versions of RA Website:
For some new implementations that we get here, most of them are turning the community more "United Statian" than "International" like it was expected to be... I honestly don't get why datetime format was needed to be changed... Sometimes this is a thing that it's not even mentioned on a PR meaning that "it's not necessarily to be mentioned because EVERYONE will approve it". RA is not a US community. It's International - and always should be as it.
RetroAchievements uses
date("d M Y, H:i:s")as default datetime format while we are forcing to usedate("M j Y, g:ia")when some new components gets implemented OR when an older component gets updated. This kind of thing already happened on Start page, Forums, Recent Players feed, Unlock achievement times and Claim expiry time on set pages and now on unlocked time on Achievements on User Profile. What would be the next one?! If this continues to happen as something arbitrary (without any real reason for that), then, it's better to change everything todate("Y-m-d H:i:s")Format which is the default one used on MySQL Database...Furthermore, the option "Show absolute dates on forum posts" also has the same issue. This comes FALSE (unchecked) as default and it's showing US datetime format on mouseover effect. If you want the default datetime format, you will need to check it (TRUE) which is something that I believe that wasn't intentional since the main intention of that feature was to just say that "a post was commented a second ago" or "this post was sent about 45 minutes ago" and so. On Mouseover Effect, the datetime was expected to give no changes. Again, no major reason to change the datetime format.
Here on Github, we have around 3-5 United Statians that contributed here, but we have about 3 users that contributed here were from Brazil. 1 user here is from Austria. 1 user is from German and so... On RA community, we have a great majority of United Statians users, but we have another majority of users that are from Brazil (like me) and users from other countries like Russia, Austria, France and so which are also present there. 24-hour format is mostly used around the World. Only US and some few countries use 12-hour format. Date arrangement change is something that is mostly used by US users.
Due to these reasons aforementioned and having knowledge that Datetime Format is something that was and still a chaos on some areas of the website. I would like to propose a new feature as a thing to be implemented on My Settings page - which would come as a matter of standardization too.
It should behave as:
FALSE:
date("d M Y, H:i:s")[Example: 21 Dec 2023, 04:04]TRUE:
date("M j Y, g:ia")[Example: Dec 21 2023, 4:04am]It would act on every point that Datetime Format can be automated via that option. Even on Audit Logs. It's about time to let Users decide the Datetime Format they want to use. NOT being a thing it's arbitrarily being implemented like it's already happening.
The only real exception would be the "(First) Released" field on Set Page since it's something that is susceptible to change anytime. Planned Maintenance would be another exceptional case since is a thing that barely occurs.
Side Note: I do NOT want this case to be dumped on "Discussions" section - since it's something that would waste all of my time writting this since: a) Github didn't give proper value to these rendering this issue to be skipped so easily and b) this is NOT intended to create any discussion or drama: it's something straight to the point of possible implementation or not ("Take it or Leave it" style). Most of my enhancement suggestions were always like this - as you can check on my previous issues on RAWeb repository history.
Beta Was this translation helpful? Give feedback.
All reactions