feat: add method to format relative time by susnux · Pull Request #921 · nextcloud-libraries/nextcloud-l10n

susnux · 2025-05-13T11:08:06Z

needed for 📅 Adjust date display in modified column to be more useful nextcloud/server#29807
replaces feat(functions): Provide formatDateTime function nextcloud-vue#6543

Lets have localization related methods together here at this place.

* needed for nextcloud/server#29807 * replaces nextcloud-libraries/nextcloud-vue#6543 Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>

artonge

Should we also expose the formatDateTime function here?

ShGKme · 2025-05-13T16:03:21Z

+	const options: Required<FormatDateOptions> = {
+		ignoreSeconds: false,
+		language: getLanguage(),
+		relativeTime: 'long' as const,


What as const does here? Isn't string always a const as it is immutable?

Type is 'long' rather than string

But you have explicit : Required<FormatDateOptions> type, which defines relativeTime as 'long' | 'short' | 'narrow' already

ShGKme · 2025-05-13T16:08:46Z

In talk-desktop the part that defines the corresponding unit is moved to an individual function, allowing to reuse it in other cases like formatDuration

https://github.com/nextcloud/talk-desktop/blob/main/src/shared/datetime.utils.ts#L72

ShGKme · 2025-05-13T16:09:16Z

Adding @Antreesy, who's worting on moment replacing functions in Talk

Antreesy · 2025-05-13T16:23:50Z

Talk implementation: nextcloud/spreed@d094cf5
Omitting the same year: nextcloud/spreed@5c99b88

for dates in pas basically that would suffice my use case;
for dates in future, would be nice if we can force .format(num, 'day') to show 'yesterday', 'today', and 'tomorrow' and day of week with new Intl.DateTimeFormat(locale, { weekday: 'long' }): nextcloud/spreed@d094cf5#diff-b727a2a5a404cfa89497bc74e8f7dab07a441e9f731b87227f96d9fd5701300cR103-R119

susnux · 2025-05-14T10:04:16Z

to show 'yesterday', 'today', and 'tomorrow'

Its already like this :)

This format was approved by the designers to be used for all our relative dates.

Antreesy · 2025-05-14T18:20:30Z

to be used for all our relative dates

Maybe that was the point =)

Discussed in person, Files and Talk have different usecases:

this PR provides a wide spectre of the time passed since the timestamp (e.g. minutes, days ago, or some date)
Talk needs:
1. Dates in past (chat separators) - <today | yesterday | 3 days ago | ''>, <day month [year]>
2. Dates in future (meeting start) - <today | tomorrow | Friday | day month [year]''>, <[hour, minutes]>

Not sure this logic would need to end up in shared library, if no other app wouldn't be using it. cc @ShGKme to proceed with own implementation in Talk

Antreesy · 2025-05-14T18:23:39Z

+	${'2025-03-01T10:00:00Z'} |    ${'long'} | ${'March 1'}
+	${'2025-03-14T10:00:00Z'} |    ${'long'} | ${'March 14'}
+	${'2025-03-14T10:00:00Z'} |   ${'short'} | ${'Mar 14'}
+	${'2025-03-14T10:00:00Z'} |  ${'narrow'} | ${'M 14'}


Not sure that would fit all cases and expected formats (e.g. March 14 and 14^th March), but still better to have in locale language

Do you have an example?

en_US and en_GB maybe? I didn't test, just popped out in my mind

https://meta.m.wikimedia.org/wiki/Date_formats_in_various_languages

I guess English would be the only overlap

I mean for different formats.

Or do you mean that we need more then a language here, not a new format?

I am not sure what this is about? It uses the format that is defined by the locale.

Not locale, but language. Works fine for English with British English, as there is British English as a language in Nextcloud).

So the question from Maksim is, are there other such cases, where there is a different locale, but there is no different language (in Nextcloud).

I still do not get the problem here? Relative time is formatted in language not locale as the format is mostly returning a "human readable" string instead of a date format (which would be the case for plain date format like "May 14 2025" vs "14 May 2025")

Yeah, it doesn't sound like a big deal, as long as month is not written as a number

It uses the format that is defined by the locale

Relative time is formatted in language not locale

Somewhere there is a typo 👀

I still do not get the problem here? Relative time is formatted in language not locale as the format is mostly returning a "human readable" string instead of a date format (which would be the case for plain date format like "May 14 2025" vs "14 May 2025")

Depends on language and locale difinition.

In Intl.RelativeTimeFormat it is locale, not a 2-digit language code.
In the context of Nextcloud — we suppose to use language, as it is not about regional format.

However, as Maksim mentioned above, there are languages with different formats, for example, English with March 14 and 14^th March in US and British. It is still March, but the format is different.

This case works correctly, as we have en and en-gb as languages in Nextcloud. Users don't need to specify a different locale here.

Not sure that would fit all cases

So the question was, are there other cases where in a single language different formats can be expected here, and not covered in Nextcloud as different languages (like en and en-gb do).

However, as Maksim mentioned above, there are languages with different formats, for example, English with March 14 and 14^th March in US and British. It is still March, but the format is different.

That is true but there is no way for us to fix this, because often people use e.g. English language but other locale to get metric units, decimal comma instead of dot or different date format.
But still I for example want the text to be "March 14" rather than having mixed English / German text like "File created vorgestern" or "File created 13. März".

So for relative time its more language than locale.

And for the special case of US vs GB English I think it is already fixed as Nextcloud will report en for US and en-GB for British English which also is the valid BCP47 code expected by the Intl.RelativeTimeFormat as locale.

feat: add method to format relative time

95c4637

* needed for nextcloud/server#29807 * replaces nextcloud-libraries/nextcloud-vue#6543 Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>

susnux requested review from ShGKme and artonge May 13, 2025 11:08

susnux added type: enhancement 🚀 New feature or request 3. to review 3️⃣ Waiting for reviews labels May 13, 2025

artonge approved these changes May 13, 2025

View reviewed changes

ShGKme approved these changes May 13, 2025

View reviewed changes

ShGKme requested a review from Antreesy May 13, 2025 16:08

Antreesy reviewed May 14, 2025

View reviewed changes

susnux merged commit 5efc8cb into main May 28, 2025
16 checks passed

susnux deleted the feat/format-relative-time branch May 28, 2025 12:24

susnux mentioned this pull request May 28, 2025

chore: prepare v3.3.0 #929

Merged

susnux mentioned this pull request Jun 19, 2025

feat(functions): Provide formatDateTime function nextcloud-libraries/nextcloud-vue#6543

Closed

3 tasks

Uh oh!

Conversation

susnux commented May 13, 2025

Uh oh!

artonge left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ShGKme commented May 13, 2025

Uh oh!

ShGKme commented May 13, 2025

Uh oh!

Antreesy commented May 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

susnux commented May 14, 2025

Uh oh!

Antreesy commented May 14, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Antreesy May 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ShGKme May 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ShGKme May 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Antreesy commented May 13, 2025 •

edited

Loading

Antreesy May 14, 2025 •

edited

Loading

ShGKme May 14, 2025 •

edited

Loading

ShGKme May 28, 2025 •

edited

Loading