Discourse uses USA date and time format

internationalization
poll
Tags: #<Tag:0x00007f29ff983048> #<Tag:0x00007f29ff982f08>

#1

Discourse uses American date and time format.
It puts month before day, and it uses am/pm system.
As a non‐US this kind of thing is not natural, especially the month/day if numbers are used for months (but which does not seem to be the case here, they use 3 letters) and more especially AM/PM system where I never know if 12 is noon or midnight as they chose some very strange rules.

I have seen the following fixed topic at meta.discourse:

They have indeed created an English (United Kingdom) set of strings at Transifex, only for the dates.
They have left the AM/PM 12‐hour clock system, it’s still not the 24‐hour clock system as maybe UK don’t use it yet…

Maybe it is difficult to use a localisation set of strings instead of genuine Discourse.

I’d just like to gather some opinions on what is the most natural (anyway all in English) date and time format:

  • Jun 12, 2018 12:18 AM / 6:12 PM (current, US)
  • 12 Jun 2018, 12:18 AM / 6:12 PM (UK?)
  • 12 Jun 2018, 00:18 / 18:12 (more European, maybe)
  • 2018-06-12, 00:18 / 18:12 (more ISO and MB, as in standard)

0 voters

※ Sometimes I see am, sometimes I see AM in Discourse.
※ Hopefully they never use 6/12/2018 (for June 12), which would be awful.
※ The poll is open until the end of this month (end of 2018).


#2

Us Brits use both 24 hour clocks and am/pm. The standard OS defaults are 24 hour clock.

PLEASE ANYTHING to kill off the daft and confusing US system. Outside of the USA I think it is only the Philippines who do backward dates.

With your voting table I would take my preferences from the bottom to the top. I prefer the ISO standard as it also works in filenames and alphabetical sorting.

Your European option is the same as the UK usually uses. Though any where it is spoken we will say 2pm or two o’clock instead of 14 o’clock.

It annoys me when things like Discourse cannot respect the Web Browser defaults for date formats.


#3

Everyone has something they like and things constantly get changed to make things “better”. I have always preferred YYYYMMDD HHMM because it makes sense to me and sorts very easy, that said, I have friends that cannot read a 24 hour clock. I have always disliked AM/PM, its redundent. When day and month are 12 or less numerically the convention MMDDYYYY or DDMMYYYY forces me to have to look further to decide which is month and which is day. Yes, I voted, and thank you jesus2099 for bring this up this. ( I’m US and also annoyed by some of our “conventions” also.)


#4

Sorry… but that made me giggle as I briefly saw it as… “I ante meridiem US and ante meridiem annoyed


#5

Yeh, that was ugly phrasing on my part, I just fixed (so as to not confuse others), thanks for the laugh, the day started off slow but is picking up. :stuck_out_tongue_winking_eye:


#6

@dashv there was also the possibility that you were trying to tune in your AM Radio…

It is almost Beer O’Clock on this side of the pond.

It does not surprise me that it is a Brit in that original Discourse article. It is not just Discourse attempting to ignore the rest of the world. Pesky Microsoft keeps trying to break our UK computers with Win10 upgrades. Every six months it would “identify” we were using the English Language and proceed to ignore all our pre-chosen options and break the keyboard layout and all the dates by swapping to English (US). The last couple of updates seem to have FINALLY learnt to leave this setting alone!

See also various annoyed Australians, Kiwis, Canada and many other English speaking countries. I notice that Hawk in the quoted thread is also a Kiwi with the same issues.

BTW - where is the pop-up coming from when I hover over the “discourse meta - 10 Dec 18” link? I notice that is a butchered time stamp of " 09:18PM 10 December 2018 "

At least this is something Wikipedia gets correct.


Even better - a little map which shows all the other countries that share date formats


#7

#8

I think all of the people outside of the US use backwards dates. I have never seen dates this way until I joined MB. In other words, we all like what we are used to. However, I’ve grown used to the dates here on MB.


#9

I certainly think YYYY-MM-DD makes the most sense and written out that would be “2018 December 15th” today.

Here in Austria we use the exact opposite “15er Dezember 2018”, which kinda makes sense in a way: If you ask someone “What’s today’s date?” you get the info that is probably most relevant to you first as you probably know which month and year it is.
But try to order a list by date with that date format.


#10

@paulakreuzer, the vast majority of people in the world are used to DMY but indeed we could use YYYY-MM-DD HH:mm for consistency with MB, even if it looks quite technical.

@IvanDobsky, it would be cool that sites would use you format of choice but I don’t think there is such a feature in browsers (only preferred languages). I think it is only a feature of operating systems.


#11

I don’t see what the excuse is. Looking at the tables on Wikipedia it isn’t that hard to check country\preferred language and then supply the normal standard for that country. Or IF {US, Philippines, Micronesia or Marshall Islands"} then MDY else DMY. Would be a simple fix that the majority of the world will then recognise.

(Why did someone start me on this subject… always been a regular annoyance of mine. :smile: It is the “World Wide Web” and not just “country software created in web”.)


#12

Based on country would not be nice, me with my French setup, connecting from USA, would get MDY because of country while all my computer is in DMY.
The OS regional setup should be retrievable by browsers, it would be great.


#13

Is your browser showing English or French? If it is a “French setup” then that would imply you’d get the French standard for regional settings.

It is a puzzle though. Too much software developed with US influence. Need more non-USAians to keep poking at this issue. The louder we shout the more likely we’ll get a solution… eventually. (A well known Norwegian web browser took an absolute age to fix this… so Discourse is not alone)

As an ex-dev I’d say the simplest answer would just be to let it be user configurable in the browser. But then I am from the older software days when customisation was more normal.


#14

I would vote for “user configuration”. No need for another “Worldwide Standard”. :exploding_head:


#15

I have gone over Discourse’s “date” strings and shuffled some of the values around so it always is either date-month-year or year-month-date and replaced 12-hour clock with 24-hour ditto. I opted for minimal intrusion in Discourse’s formatting, so I didn’t change all strings to follow ISO 8601 at this time (even if it’s the clear “winner” of the poll, and also the one I voted for :slight_smile:). At this point I’d rather stick closer to Discourse’s defaults than change everything completely. I may change my mind on this though, so feel free to let me know if you strongly think we should go all-in on ISO 8601.

And also let me know if you spot anywhere where the date somehow got placed in between month and year still.

User configuration is not something I can do from my side. You should bring that request upstream to Discourse. We’re unlikely to do custom hacking on the code like this anytime soon.


#16

It’s great already!
Would it make sense to change 17 Dec, 2018 11:51 to either 17 Dec 2018, 11:51 or 17 Dec. 2018, 11:51?
Or is it wrong?


#17

Just loose the comma 17 Dec 2018 11:51

But don’t try and test this tomorrow - especially around twenty past six in the evening. 18 Dec 2018 18:18


#18

To me the date was to much broken into two pieces with unnecessary comma before year.

And date and time were too much together, laking a separator, it visually seemed that 2018 was related to following time, hard to read time without seeing the year.


#19

Added a comma. Does it look okay?


#20

@Freso
It’s super on PC!!
But not yet fixed on mobile, whrere I still see comma before year and no comma between year and time:
wp_ss_20181218_0001%20(2)