Review date/time localisation in editorial backend

[jardakotesovec]

Update 2025-06-03

• Given that we have configurable dates, that can be configured per journal and language I focused on applying these formats in the browser for client side rendering

• As described in original issue, per my testing I was not getting localised dates in 3.3/3.4 from moment library. Nor these would be consistent with date formats configured above. On the other hand there was not many use cases displaying dates in Vue.js.
• Migrated to successor library - Luxon.
• Luxon rely on the Intl capabilities of the browser. Therefore it does not include per locale configurations and rely on browser and OS to provide these. The coverage will vary per browser/platform. My hope would someone using certain language would be using platform that supports given language and will also have Intl configuration available, but don't have data to back it up. If we get feedback that Intl is not providing good enough support, we can look into some Intl polyfills for some specific languages. Or alternatively dateFns has decent locale support, but we would have to include these to the package.
• Fallback is to english locale
• PHP DateTime format is transformed to the Luxon compatible format. Can't guarantee 100% same results from php and JS date formatting, but should be very close.
• At this point we leverage date short and datetime short formats on client side. We did not have need to use the longer ones yet.

PRs
ojs:pkp/ojs#4720
ui-library: pkp/ui-library#553
pkp-lib: #11043

Original Description

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 #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 🙂
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 :)

[jardakotesovec]

Have we got any conclusion on this? Its for sure complex topic, but looking into whether I should squeeze in some improvement for 3.5.

If we would like to go with localised date formatting, than just following UI or Journal locale does not cut it - even just for GB/US difference which we don't differentiate with our language options.

One option I was considering is to use navigator.language, which is the locale that users browser is in. So its quite likely thats the formatting he would understand&appreciate. Maybe having option to override it in his profile would help with edge cases.

Currently we are using mostly this formatting.. which also could be option for now as discussed above.

2025-03-12 

@Devika008 @asmecher

[asmecher]

I did make some 3.5 back-end improvements in #10264, mostly around using Carbon for date representations and using Carbon and intl functions to convert to localized date forms. But I do think this should be replaced by client-side formulation of dates, informed browser-side local time zone and localization tools. I don't know that part of the ecosystem well enough to comment on when we're ready to make that leap. However, we get very little feedback on the actual date formatting, so I don't consider it a showstopper to continue with what we currently have.

[jardakotesovec]

For reference there is good conversation about this topic #5540

As result of that ticket, it seems that we already have pretty good settings options per journal and language. I was not aware of that.

Therefore first thing that comes to mind is to make sure that these settings gets respected, also on client side date formatting.

[jardakotesovec]

Updated the description in first ticket, so its clear what changes are going to be included in 3.5

@blesildaramirez Can you please do the code review? Thank you.

[jardakotesovec]

@Tribunal33 Merged to main&stable-3_5_0. Ready for testing.