There’s also this post on the forum from only 2 months ago
in support of his feature request. But as it turns out, the post wasn’t from Dec 13 - it was from Dec '13. I since have changed the relevant strings in my install from 'YY to YYYY to avoid this confusion, but given we’ll be living in a world where this confusion will keep happening until 2031 and stay relevant for old posts well into the 2040s, I’d say it’s worth changing everywhere. The clarity gained from “hey watch out you’re digging deep in the archives” is well worth the additional 1.5 characters.
It also solves some i18n issues - '24 is already informal in English, and very unusual everywhere else AFAICT. 2024 meanwhile is well-understood everywhere and a better international default.
I see no arguments in favor of keeping it as 'YY in any of these threads, not on a UX design level anyway. I do see various people, including the man himself, give an excellent use case as to what the benefit to this change would be:
The fix for this seems to be a simple text replacement for 'YY → YYYY, avoiding a couple matches where ' is used as the beginning of a string instead. I can make that PR.
I would like to see it following language settings because american way to show dates (among all others ) is really confusing and I just don’t see the difference between Feb 14 and Feb ’14
And disclaimer.
It is possible it is actually following language setting, because I have here US-settings (sorry britons…). But I don’t think so because Discourse loves short dates and english for example is not another universal system how to show time, mass, lenght etc.
Not a big thing. I edited dates on my forum, and difference between date and year isn’t real issue here. Automated bumps are…
@Jagster What’s your locale and the preferred formatting for “month and day” and “year and month” type displays? I see the relevant files and might as well localize them properly (instead of copying over just the solution I’m proposing for en-US) while I’m at it.
There are a lot different options. But should that be default? I don’t think so because majority of global audience don’t prefer it? I don’t know if that’s true. I only know that I see it very confusing it.
And again… minority of the world uses very unlogical MMM DD ’YY format. It’s as strange than headers Where Is Everything In Capital, Commas, Strange, List that is very american way too
Totally same to me and we have very disturbing limits how to use OpenAI and Dall-E too only because of americans
My weak point is we all have learned live with those stranger things and I’m totally happy if I can change those as I want no matter what defaults are. But I have gut feeling that quite many anglos don’t understand format MMM ’YY either.
Do we have too much free time, because this is not that important thing
@darkpixlz There certainly is a wider discussion to be had about what date formats to show when, though I’d like to keep that separate from this discussion. Such a discussion would need deeper research on the use of the 'YY pattern in multiple locales, to ensure that the default isn’t confusing elsewhere.
This discussion in particular aims to solve the issue of “Feb '22 and Feb 22 get confused quite often”, and the most conservative fix to this issue is to use Feb 2022.
It’s a small and actionable request which ideally doesn’t require a lot of discussion. It is completely possible to discuss it to death and to get stuck in preferences and bikeshedding, and I’d like to avoid that.
We have a UX problem here, and we have a solution - let’s get that in, and discuss the rest elsewhere.
This change needs to be updated in other languages. Currently, only the “en” version has been changed. I believe it might be sorted out when the translations will be updated on Tuesday I believe (?).
) is really confusing and I just don’t see the difference between Feb 14 and Feb ’14
