Review date/time localisation in editorial backend

[jardakotesovec]

Describe the issue While doing code review for PR I was looking for correct way how to adjust following date formatting statement to reflect current locale.

function formatShortDate(dateString) {
    return moment(dateString).format('DD-MM-YYYY');
}

Given that we have getMomentLocale function I assume that moment works with locale.

Tried things like

  return moment(dateString).locale('fr').format('l');

But the problem is that for moment.js to be able to format per locale - each individual locale needs to be explicitly loaded

import 'moment/dist/locale/fr'; // Import French locale

I did test it with 3.3 and 3.4 and main. And all of them had only 'en' locale which is always present.

Solution Probably start relying on some modern library which is leveraging native browser functionality for formatting dates, so we don't have to include extensive locale specific data for so many languages.

[jardakotesovec]

@asmecher @bozana @Vitaliy-1 Please let me know if you have some additional context to this issue.

[asmecher]

@jardakotesovec, I can't help much with browser-side localization, but we did recently have to replace our use of (localized) strftime on the PHP side, as it was deprecated. Unfortunately much of our use of strftime is via Smarty's date_format function, which they've apparently chosen not to replace until PHP9. So our server-side date formatting is also somewhat in flux. For parts of date formatting that have been migrated away from strftime (that is, parts that are not Smarty date_format based) we have a configuration mapping from strftime conventions to date conventions; see PKPString::getStrftimeConversion.

[Vitaliy-1]

I remember working date formatting and moment.js in the DateTimeForm.vue. I don't see an explicit locale import there or am I missing something? Looks like moment.js folks recommend to migrate to the Luxon

[jardakotesovec]

@Vitaliy-1 When investigating yesterday, I noticed some devs claiming that when moment.js used with webpack - it would bundle all locales. So maybe that was the case in past and maybe thats why it was working in past. And I did expect this to be the case for 3.3 and 3.4, but surprisingly when I called moment.locales() it listed only ['en']. So maybe it already regressed with some moment.js or webpack version update, not sure.

[jardakotesovec]

Moment.js provides good list of recommendations what to use as modern replacement - https://momentjs.com/docs/#/-project-status/recommendations/

Given our wide range locale support - we would need to bundle way too many locale specific configurations and maintain the list. I think browser support for Intl.DateTimeFormat is good enough to rely on that instead at this point.

Given this assumptions we have two options

• using Luxon, which is basically moment.js successor and relies on the browser Intl API
  • using directly Intl Api.

Moment.js docs points out that browsers are inconsistent on date parsing ('yyyy-mm-dd') format which we use a lot. Therefore adopting Luxon which address these inconsistencies, plus give us some useful functions to for example calculate number of days between two days seems like convenient way forwards.

I was interested to know what locales the Intl API supports. And was not really able to find anything else than just directly check via Intl.DateTimeFormat.supportedLocalesOf(['de',...]) in my browser.

Therefore I tried to dump the languages.csv file on it to see how much it will tell it supports and got 142 from total ~720 in languages.csv.

In comparison to what moment.js offers - they have 138 locales. From this simple comparison I would conclude that Intl.DateTimeFormat is not falling behind.. and will get better as the browsers/OSs improves the locale support.

Tagging @ajnyga in case have some suggestions or ideas how to push this even further.

[jonasraoni]

In the past I've used date-fns, but Luxon is the natural choice, given it's maintained by the moment folks (smaller probability of missing features when updating).

I guess the languages.csv reference is coming from here https://github.com/pkp/pkp-lib/issues/9707, while both issues are scheduled for 3.5, it makes sense to ignore the current/older locales :)

[Devika008]

Coming from a completely different design perspective, I researched a bit into this and audited different standards and websites and I believe that we should follow ISO 8601 standard.

This means that we should be following formats

1. Date: YYYY-MM-DD
2. Time: hh:mm:ss where hh refers to the zero-padded hour between 00 and 24
3. Date and Time together: YYYY-MM-DD hh:mm:ss

For example, 11.15pm on 19th March 2024 will be expressed as 2024-03-19 23:15:00

[ajnyga]

I am maybe not convinced if localisation for dates is a good idea but this has been a feature we've had.

Luxon mentions

Luxon DateTimes can be configured using BCP 47 locale strings specifying the language to use generating or interpreting strings.

https://moment.github.io/luxon/#/intl?id=how-locales-work

So this should work ok with our choice of using the Weblate list which is based on BCP47.

[Devika008]

Hello,

I think it will be meriltuous for me to explain the rationale behind me proposing a unified format for date in the platform. I'm presenting a few snippets from a thorough research I conducted along with a suggestion that I think could work for everyone.

1. There are multiple local conventions followed. I strongly believe that if we cater to some then we need to cater to all and make sure we are inclusive. After observing and studying different systems around the world who navigated to a unified date and time formats along with participating member countries of the ISO standard, i believe a lot of nations and policies are promoting its use including many Arabic countries. It will keep us safe from different controversies or further exposure as we are following an international principle.

2. Following the ISO convention is also a recommendation by W3C accessibility guideline

Advantages of the ISO 8601 standard date notation compared to other commonly used variants. These advantages about been included in many research papers recently on the topic.

1. easily readable and writeable by software (no ‘JAN’, ‘FEB’, ... table necessary)
2. easily comparable and sortable with a trivial string comparison
3. language independent
4. can not be confused with other popular date notations
5. consistency with the common 24h time notation system, where the larger units (hours) are also written in front of the smaller ones (minutes and seconds)
6. strings containing a date followed by a time are also easily comparable and sortable (e.g. write “1995-02-04 22:45:00”)
7. the notation is short and has constant length, which makes both keyboard data entry and table layout easier
8. identical to the Chinese date notation, so the largest cultural group (>25%) on this planet is already familiar with it :slightly_smiling_face:
9. date notations with the order “year, month, day” are in addition already widely used e.g. in Japan, Korea, Hungary, Sweden, Finland, Denmark, and a few other countries and people in the U.S. are already used to at least the “month, day” order
10. a 4-digit year representation avoids overflow problems after 2099-12-31

My Suggestion

We promote a standard as it helps streamline and invite a lot of globalised effort with the flexibility of users wanting to change the format for their OJS installations and themes if they wish to

[asmecher]

Just about the entire software world uses ISO8601 for shuttling dates between systems. Beyond storage and import/export (where ISO8601 is fine) we really only have two requirements:

• Accept dates from the user via the UI, and
• Present dates to the user via the UI

I think both of these can be pushed as close to the browser as possible using 3rd-party libraries, where intl support will be closest in alignment with the user's expectations.

Devika, this is close to what you're proposing, except that it doesn't throw the baby out with the bathwater by 100% dropping support for localized dates.

[asmecher]

(We do have a community that wants to use OJS with Jalali dates, and it's been a longstanding challenge for them to do that. See e.g. this forum thread. But it appears that good 3rd-party libraries that we might consider also miss this support.)

[Devika008]

100% agree with you Alec :D Thank you so much for bringing this to light was not aware of the Forum thread before you mentioned it

[jonasraoni]

The standards are great, such as the numeric system, international system of units, and I'd love to have a unified language too, it would be much easier to share information.

But people are complex and love their creations (e.g. imperial system of units). We need to give what they want :)