Does the current proposal make sense outside of the gregorian calendar?

[rxaviers]

Update: this can be solved by using a calendar option as Zibi suggests below.

---

Problem

The current proposal takes a number of ms as argument and calculates the correspondent second, minute, ..., year for formatting, being a positive in the future and a negative in past, which seems very sane.

It happens that some calendards have different months and years lengths [1]. Thankfully, the equation (used here for deducing time units) should always work for seconds, minutes, hours, and days, but it might fail for deducing months and years. For example, in the Chinese Calendar there are 12 or 13 months; in the Islamic Calendar, there are 354 or 355 days year.

In a general sense, e.g., suppose a developer is writing a game where he needs to display the relative time of Martian months, the current calculation doesn't make sense. Note that in this example case, it doesn't make sense even for day.

General thoughts

Above we have a good and a bad news. The bad news is that the problem lies in the calendar calculation and that's usually a tough problem. The good news is that it doesn't have anything to do with internationalization/localization (i18n).

The i18n problem is very simple, it's to display the localized message, e.g., 10 seconds ago where numeric value is -10 and unit is second. Additionally to this problem is whether or not the formatted text is integer or decimal, because it could change the plural form.

The calendar calculation problem is whether or not a bunch of ms corresponds to a bunch of months.

The current relative time proposal tries to solve both problems. It would be easier if it sticks with the i18n problem only.

Any thoughts?

1:

• In the Chinese Calendar there are 12 or 13 months https://en.wikipedia.org/wiki/Chinese_calendar and http://www.math.nus.edu.sg/aslaksen/calendar/cal.pdf
• In the Islamic Calendar, there are 354 or 355 days year. https://en.wikipedia.org/wiki/Islamic_calendar
• More calendars https://en.wikipedia.org/wiki/List_of_calendars.

[rxaviers]

My question is definitely about non-gregorian calendars, so I'm changing the title.

I've also edited the description:

- My initial questioning was "Does the current proposal make sense outside of the gregorian calendar?", but while writing this description I thought I should take the risk of making the question even more generic. Here it goes:

[caridy]

@rxaviers this is a great insight. we certainly never came across this problem.

the calendar calculation and that's usually a tough problem. The good news is that it doesn't have anything to do with internationalization/localization (i18n).

I don't totally agree with that assertion, I think that's something we have to provide some how, whether that's via this API or another.

At first glance, this means we will have to revisit the API, reach out to other folks for more insight about this calendar computations required by this component, and iterate. Ultimate, we can go with what you described, which is the minimum requirement for users to format a unit into the corresponding relative time.

[zbraniecki]

@caridy, why in #7 you said that this would prevent us from using bestfit? This problem sounds to me like a reason to add calendar option which follows the selected language and can be overridden manually. Am I missing something?

[rxaviers]

This problem sounds to me like a reason to add calendar option which follows the selected language and can be overridden manually

Good point! It's a clear solution for this problem in terms of API. Probably, no one will be able to actually use it though until Date supports non-gregorian calendars too, but that's a different problem.

[rxaviers]

The question has been solved, I've opened #13 to polish the API update for this new option.