Suffix for date display?

[Wysardry]

I've been experimenting with the cofiguration file on a test site, but have not been able to find a way of formatting the dates to include a suffix (st, nd, rd or th) after the day of the month.

For example, I would like to display "31st May, 2023" instead of "31 May, 2023".

Is there a built-in way to do this?

[Kwpolska]

Nikola's date formatting is based on CLDR. I can't see anything that would produce 1st/2nd in the CLDR date field symbol table. Adding those would require either custom JS (which is ugly) or changing Nikola's source code with some manual date formatting — so it might be better to stick to a simpler format.

[Wysardry]

I couldn't find the option in the CLDR or LUXOR docs either. I remember it being an option with PHP date formatting though (not that that helps).

The main reason I would like a suffix on dates is for screen readers. It wouldn't be too annoying if only a couple of dates were on a page, but I would imagine it would become so with the number of dates on index pages.

Would adding custom pretty_date and pretty_modified metadata fields cause any issues with existing variable names?

[sukiletxe]

The main reason I would like a suffix on dates is for screen readers. It wouldn't be too annoying if only a couple of dates were on a page, but I would imagine it would become so with the number of dates on index pages.

I can't (and shouldn't!) speak for all users, but I'm a screen reader user and I don't care.

[Kwpolska]

The main reason I would like a suffix on dates is for screen readers. It wouldn't be too annoying if only a couple of dates were on a page, but I would imagine it would become so with the number of dates on index pages.

I would imagine that screen readers understand dates and would read them nicely, did you test how some common screen readers behave?

Would adding custom pretty_date and pretty_modified metadata fields cause any issues with existing variable names?

It shouldn't.

[Wysardry]

I would imagine that screen readers understand dates and would read them nicely, did you test how some common screen readers behave?

I haven't done that yet, no. I have seen mention of the problem in articles such as this though.

I would rather take the extra time to avoid this potential issue, even if it would only affect a small percentage of vistors.

Would adding custom pretty_date and pretty_modified metadata fields cause any issues with existing variable names?

It shouldn't.

Then I should be able to manually add "prettier" dates to post metadata and modify the templates to display them without affecting the time HTML tags or Nikola's sorting routines, right?

[Kwpolska]

You should be able to do that, but I personally wouldn’t spend too much time on this without testing first. The article you linked to is from 2007, things have changed a lot since then. The default templates of Nikola use a <time> tag, which might help any tools figure out they’re looking at timestamps (and note that <time> was not a thing in 2007).

[Wysardry]

Even if I could be 100% sure that none of my site visitors would be using an older screen reader I would still want the date suffix included as it looks ugly to me without one.

I will likely need to modify several of the template files anyway, as the site will be a digital garden rather than a blog or website.