Change to DD Mmm / Mmm 'YY for post dates

What our users don’t complain about so far (by descending priority):

  • relative dates for posts less than a week old.
  • DD Mmm for posts older than a week in the current year.
  • MM YYYY for posts before the current year. (but french market, so YYYY/MM may be more suitable for an international audience)

Self-correct: yes, during the first week and month of the year, dates mostly fall in the 3rd category, but really, no one cares.

Are there any plans to fix this? we would like to use a full date too on


For what it’s worth, this is actually relatively straight forward to patch when bootstrapping the image. In your yml file (standalone or web), in the same section that pulls in the plugins:

    - replace:
        global: true
        filename: /var/www/discourse/config/locales/client.en.yml
        from: /"MMM .YY"/
        to: "\"MMM YYYY\""
    - replace:
        global: true
        filename: /var/www/discourse/config/locales/client.en.yml
        from: /"MMM D"/
        to: "\"D MMM\""
    - exec:
        cd: $home/plugins
          - mkdir -p plugins
          - git clone

The two replace sections are the meat of it, the rest is for context. They massage the default English localization (en) to change the formats in question. Edit the replacement formats to taste.

I don’t actually run with the second one any more, as I think the first replacement does enough to distinguish the month-year pattern from the month-day one. And it’s not like those 10 or so extra pixels spent on the 20 vs ' were doing something else otherwise. :slight_smile:


We plan to add support for customising the strings via ui, will make sure it happens earlier in the release rather than later

1 Like

Hey Sam,

thanks for the update!

I just got hit by this on:

Aug 11 reads to me as “August 2011”, I think we should just at least swap stuff around for dates… 11 Aug is just so much less ambiguous and a trivial change.

Should I go ahead and do that?

1 Like

Probably fine, but technically it is Aug 11 vs Aug '11

Some of our users complained about the clarity of the post date, e.g:

Oct '14
Oct 15

It’s very easy to ignore that apostrophe…

Anywho, there is any way of showing full year?


1 Like

(Merged your topic in here) Not quite yet, but it’s planned:


I just had an idea - hacky, but it’s better than nothing: what if we use some css for yearly posts?

So here is what i did:

span.relative-date.with-year:before {
  content: attr(title);
  font-size: 14px;

span.relative-date.with-year {
  font-size: 0;

And here is how it looks like:

A bit verbose, but i guess it’s better than nothing. :blush:


Repost of solution as requested by erlend_sh:

Use Admin > Customize > Text Content

search for 'YY which will list:




MMM D, 'YY <br/>LT

Edit and adjust those replacing 'YY with YYYY to get the full year.


Just in case anyone wants to change from the Month-Day format to the (internationally more common) Day-Month format: to find all relevant Text Content elements (quite a few actually), it’s best to search for MMM.

UPDATE: I just realized that searching for MMM will not give you all relevant Text Content elements. (For example, dates in emails will still remain the same. Try searching for date.

Some of the text elements that you need to change are using a different notation, such as %B %-d, %Y I believe it is Ruby. To understand and change them, this might be useful:

Format directives:

Date (Year, Month, Day):
%Y - Year with century if provided, will pad result at least 4 digits.
-0001, 0000, 1995, 2009, 14292, etc.
%C - year / 100 (rounded down such as 20 in 2009)
%y - year % 100 (00…99)

%m - Month of the year, zero-padded (01…12)
%_m blank-padded ( 1…12)
%-m no-padded (1…12)
%B - The full month name (January'') %^B uppercased (JANUARY’’)
%b - The abbreviated month name (Jan'') %^b uppercased (JAN’’)
%h - Equivalent to %b

%d - Day of the month, zero-padded (01…31)
%-d no-padded (1…31)
%e - Day of the month, blank-padded ( 1…31)

%j - Day of the year (001…366)

Time (Hour, Minute, Second, Subsecond):
%H - Hour of the day, 24-hour clock, zero-padded (00…23)
%k - Hour of the day, 24-hour clock, blank-padded ( 0…23)
%I - Hour of the day, 12-hour clock, zero-padded (01…12)
%l - Hour of the day, 12-hour clock, blank-padded ( 1…12)
%P - Meridian indicator, lowercase (am'' orpm’’)
%p - Meridian indicator, uppercase (AM'' orPM’’)

%M - Minute of the hour (00…59)

%S - Second of the minute (00…60)

%L - Millisecond of the second (000…999)
The digits under millisecond are truncated to not produce 1000.
%N - Fractional seconds digits, default is 9 digits (nanosecond)
%3N millisecond (3 digits)
%6N microsecond (6 digits)
%9N nanosecond (9 digits)
%12N picosecond (12 digits)
%15N femtosecond (15 digits)
%18N attosecond (18 digits)
%21N zeptosecond (21 digits)
%24N yoctosecond (24 digits)
The digits under the specified length are truncated to avoid
carry up.

Time zone:
%z - Time zone as hour and minute offset from UTC (e.g. +0900)
%:z - hour and minute offset from UTC with a colon (e.g. +09:00)
%::z - hour, minute and second offset from UTC (e.g. +09:00:00)
%Z - Abbreviated time zone name or similar information. (OS dependent)

%A - The full weekday name (Sunday'') %^A uppercased (SUNDAY’’)
%a - The abbreviated name (Sun'') %^a uppercased (SUN’’)
%u - Day of the week (Monday is 1, 1…7)
%w - Day of the week (Sunday is 0, 0…6)

ISO 8601 week-based year and week number:
The first week of YYYY starts with a Monday and includes YYYY-01-04.
The days in the year before the first week are in the last week of
the previous year.
%G - The week-based year
%g - The last 2 digits of the week-based year (00…99)
%V - Week number of the week-based year (01…53)

Week number:
The first week of YYYY that starts with a Sunday or Monday (according to %U
or %W). The days in the year before the first week are in week 0.
%U - Week number of the year. The week starts with Sunday. (00…53)
%W - Week number of the year. The week starts with Monday. (00…53)

Seconds since the Epoch:
%s - Number of seconds since 1970-01-01 00:00:00 UTC.

Literal string:
%n - Newline character (\n)
%t - Tab character (\t)
%% - Literal ``%’’ character

%c - date and time (%a %b %e %T %Y)
%D - Date (%m/%d/%y)
%F - The ISO 8601 date format (%Y-%m-%d)
%v - VMS date (%e-%^b-%4Y)
%x - Same as %D
%X - Same as %T
%r - 12-hour time (%I:%M:%S %p)
%R - 24-hour time (%H:%M)
%T - 24-hour time (%H:%M:%S)


To summarize my experience of changing the time and date format to a more internationally compatible format: it is quite a chore as it feels like you have to make the same change over and over again in different variables. It would be great to eventually see this as a more user friendly site setting and I assume this is already on the team’s list. So here is my +1 for that.


Addendum: there is at least one more field to change which you won’t catch with any of the above searches: short_no_year

It’s for how the date shows up in summary emails.

Edit: and two more time.formats.short and time.formats.long


Hmm… now that we do have lots of ancient content… maybe we should revisit this… on hits from Google it is not super obvious you just landed on Ancient Content ™.

I feel this topic would be clearer if it said “Oct 2015” vs “Oct '15” … That said… if we wait till 2032 this is going to be a lot less of a problem. :face_with_raised_eyebrow:


No, it won’t start not being a problem until 2032 is “old” , which is going to be at least another few years afterwards!