Support Unicode Technical Standard #35 format in @gravity-ui/date-utils

[korvin89]

Why we may need it?

Currently in @gravity-ui/date-utils a moment-like format is used. Using this approach has several disadvantages:

• To implement this approach, it's necessary to have separate files for each locale, for example, this is how it looks in dayjs, which we use in our library. This directory contains 142 files, each up to ~100 lines of code, which makes loading locales in date-utils happen asynchronously.
• When using moment-like format, you cannot use standalone tokens. For example, the format 'D MMMM' in ru locale will always return '25 Февраля' because it uses complex logic that needs to be repeated for each locale.

Within this RFC, it is proposed to switch to using the Unicode Technical Standard #35 format. Below I suggest we consider its advantages and disadvantages and decide whether we want to switch to it.

Advantages:

• Using Intl for translating date tokens
• This is a big step towards abandoning dayjs
• Using standalone tokens

  'd MMMM' // 25 февраля
  'd LLLL' // 25 февраль

• No need to load required locales when using (if not using humanize duration or ordinal dates)
• Using a generally accepted standard

Disadvantages:

• Changing the familiar format. Let's imagine it's 25.02.2025 and we call the method dateTime().format(format) in our browser, where format is a pattern from the table below:

  Moment-like	UTS Add support for generic in value prop to Select in gravity-ui #35 based	Result
  D	d	25
  YYYY	yyyy	2025
  DD.MM.YYYY	dd.MM.yyyy	25.02.2025
  L	P	02/25/2025

  The full difference in formats can be seen at these links: Moment-like | UTS #35 based

• We will have to describe humanize duration and ordinal dates ourselves for each locale, here's an example for the ru locale. This part of localization will have to be loaded asynchronously (just as it is done now for all locales)

[arteria32]

question:
What does "humanize duration" mean? Intl can translate duration

[ValeraS]

Currently Duration from @garvity-ui/date-utils has two methods humanize and humanizeIntl. These methods produce slightly different results. The first one generates a string according to dayjs locals rules, and the second one - according to Intl. For example:

d = duration({
    years: 1,
    months: 2,
    weeks: 1,
    days: 3,
    hours: 4,
    minutes: 5,
    seconds: 6,
    milliseconds: 7,
 });
d.humanize() === 'a year';
duration({seconds: 44}).humanize() === 'a few seconds';
duration({seconds: 45}).humanize() === 'a minute';

d.humanizeIntl() === '1 year, 2 months, 1 week, 3 days, 4 hours, 5 minutes, 6 seconds, 7 milliseconds';
duration({seconds: 44}).humanizeIntl() === '44 seconds';
duration({seconds: 45}).humanizeIntl() === '45 seconds';