-
Notifications
You must be signed in to change notification settings - Fork 4
feat: add method to format relative time #921
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
* needed for nextcloud/server#29807 * replaces nextcloud-libraries/nextcloud-vue#6543 Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
artonge
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we also expose the formatDateTime function here?
| const options: Required<FormatDateOptions> = { | ||
| ignoreSeconds: false, | ||
| language: getLanguage(), | ||
| relativeTime: 'long' as const, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What as const does here? Isn't string always a const as it is immutable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Type is 'long' rather than string
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But you have explicit : Required<FormatDateOptions> type, which defines relativeTime as 'long' | 'short' | 'narrow' already
|
In https://github.com/nextcloud/talk-desktop/blob/main/src/shared/datetime.utils.ts#L72 |
|
Adding @Antreesy, who's worting on moment replacing functions in Talk |
|
Talk implementation: nextcloud/spreed@d094cf5
|
Its already like this :) This format was approved by the designers to be used for all our relative dates. |
Maybe that was the point =) Discussed in person, Files and Talk have different usecases:
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 |
| ${'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'} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have an example?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean for different formats.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or do you mean that we need more then a language here, not a new format?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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")
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it doesn't sound like a big deal, as long as month is not written as a number
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
formatDateTimefunction nextcloud-vue#6543Lets have localization related methods together here at this place.