Issue with date-time translations, losing the default format

[bladx]

Checklist

• I have read the contributing guidelines.
• There is no similar request on existing issues (including closed ones).
• I have read the project progress and know the current progress of the project.
• I was in the master branch of the latest code.

Is your feature request related to a problem? Please describe

I recently migrated to chirpy-starter and first I want to say that I really appreciate this tools that simplify a lot the repository content. But I have an issue with date-time translation.

In the _config.yml file, I use:

lang: fr-FR
prefer_datetime_locale: fr

But the date-time for posts (list items and detail page) is not as in default English: "Aug 9, 2019" (in French) but: "2019-08-09".
Same for archives, I got: "09 / 08" instead of default English :"09 Aug".
Only the tooltip of post's detail is well translated from default English: "Fri, Aug 9, 2019 2:55 PM" to: "ven. 9 août 2019 14:55" (actually we are losing the case).

Describe the solution you'd like

I would like to have the same date-time format as in English but translated in the language I did choose.
Either an option to define date(-time) formats (for example in French, the date is displayed as: DD/MM/YYYY for example.), or using the same format as the default one for English.

I believed this current behavior is due to those two parts of the code:

1. _includes/datetime.html

{% if site.prefer_datetime_locale == 'en' or lang == 'en' %}
  {% assign df_strftime = '%b %e, %Y' %}
  {% assign df_dayjs = 'll' %}
{% else %}
  {% assign df_strftime = '%F' %}
  {% assign df_dayjs = 'YYYY-MM-DD' %}
{% endif %}

2. _layouts/archives.html

{% if site.prefer_datetime_locale == 'en' or lang == 'en' %}
  {% assign df_strftime_m = '%b' %}
  {% assign df_dayjs_m = 'MMM' %}
{% else %}
  {% assign df_strftime_m = '/ %m' %}
  {% assign df_dayjs_m = '/ MM' %}
{% endif %}

Describe alternatives you've considered

I know I could migrate back to jekyll-theme-chirpy instead of using chirpy-starter. And then edit the two codes parts to the following:

1. _includes/datetime.html

{% assign df_strftime = '%b %e, %Y' %}
{% assign df_dayjs = 'll' %}

2. _layouts/archives.html

{% assign df_strftime_m = '%b' %}
{% assign df_dayjs_m = 'MMM' %}

But I feel like this should be part of the configuration and that chirpy-starter may use this.

Additional context

Actually I did try to do the alternative solution (that works well). But when choosing that, there were like a 300ms time where the value of the date-time was not translated yet when displaying a page.
So this might be the reason why this workaround has been done.
But I don't feel like this is the right way. I don't know if we could display this value only after it has been translated?

[cotes2020]

Explain to you how the datatime is rendered:

1. Jekyll SSG uses strftime format to build HTML pages, and this is what was observed for the first time.
2. JS will later update the local time based on the visitor's region.

Unfortunately, the format of strftime is not strong enough to support internationalized local time. If different time formats are used between 1 and 2, a text jitter will occur. So in languages other than English, I choose to use YYYY-MM-DD

[bladx]

Thanks a lot @cotes2020 for the explanations!
This is now very clear about the behavior I faced when using a date-time format with string in it.

Do you think it could be somehow possible to have new dedicated configuration properties for both:

• "long date", currently YYYY-MM-DD, used for posts items and detail
• "short date", currently DD / MM, used for archives items

In order to be able to override the default date format when using another language than English?

This would allow me to use DD/MM/YYYY as "long date" format which is a digits only format and closer to the "short date" format that already suits my needs (and is actually what we use in French).

[cotes2020]

Unlikely to do so, as it was the old way. See: a5d38e7.

Mixing Dayjs and Strftime requires specifying different date formats respectively, which will increase the cost of multi-language switching.

[bladx]

Ok thanks, I do understand although I would have liked an alternative to be able to choose the date format.
I will keep the current behavior of Chirpy starter as it facilitate too many things to go back to a custom Chirpy project.
Thanks again for the awesome work (and the time you took to explain me the reason behind)! :)

[cotes2020]

So, I've restored some configuration options in date-time format. It should now be more suitable for worldwide time formats.