Get rid of dayjs from @gravity-ui/date-utils

[hozblok]

Objective

The part of work to remove the dependency of dayjs has already been done. The part related to i18n remains.

Solution Proposal

1. Create concept to implement new i18n model.
2. Get rid of i18n with dayjs
3. Remove dayjs.
4. Simplify the library by removing singletonism.

[korvin89]

сс @ValeraS

[arteria32]

Objective

The part of work to remove the dependency of dayjs has already been done. The part related to i18n remains.

Solution Proposal

1. Create concept to implement new i18n model.
2. Get rid of i18n with dayjs
3. Remove dayjs.
4. Simplify the library by removing singletonism.

Note:
I think you miss a one step (mb, first step): implement a method to decode timestamp from string.

In this method dayjs.locale need only to getting preset of locale aware formats:

Steps of algorithm

1. In date-utils apply a plugin customParseFormat
2. Call a function to parse string with specific format
3. Make a parser by input format string and locale settings
4. Check a locale aware format in locale dictionary

cc:@hozblok

[arteria32]

What do you think about using Intl.DateTimeFormat and Intl.RelativeTimeFormat instead of dayjs.locale? It is an embedded ECMAScript internationalization API.
In comparison to a full rewrite of dayjs.locale, using an embedded tool can reduce the cost of implementation and support.

сс: @ValeraS, @korvin89

[arteria32]

Idea for sharing configuration between packages to avoid the necessity of a singleton:
I suggest using a globalThis for sharing config of date format or selected language.
Example - run node ./main.js

[arteria32]

Hi, @korvin89.
After we had discussed my idea with you, I thought of a mechanism to share configuration without singletons.

I didn't achieve any results. I think that sharing data is always based on a singleton.

IMHO, my solution can remove some constraints. A singleton object can be moved from a package to an environment, and after that, users can create several instances of it. Is the game worth it?

If you design a more effective and less costly solution and need help, I would be happy to help.

[korvin89]

@arteria32 It seems to me that the current approach looks safer. If two versions are used on the project, this can lead to difficult-to-diagnose problems when more than one version of the library tries to write something to a global object

[SeqviriouM]

@korvin89 @arteria32 can you share the current status? Have we agreed on the final format and is it possible to start development?

[korvin89]

@SeqviriouM

1. Create concept to implement new i18n model. // Done
2. Get rid of i18n with dayjs // In progress
3. Remove dayjs. // Planned
4. Simplify the library by removing singletonism. // This point looks controversial, I'm not quite sure that we will do it