non Georgian calendars

[mhf-ir]

We have many types of calendars that use in many countries. https://github.com/unicode-cldr/cldr-core/blob/218129a0ead6f82b1b7e4c146e4264f3b475c303/supplemental/calendarPreferenceData.json

Any plan for implementation ?

[iamkun]

I'm not familiar with the concept of non Gregorian calendar. Any detailed information?

[mhf-ir]

More detailed on JS: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat Example:

console.log(new Intl.DateTimeFormat('fa-IR-u-ca-persian').format(new Date()));

Browser support: http://kangax.github.io/compat-table/esintl/

php version with intl extension:

$fmt = datefmt_create(
    'fa_IR@calendar=persian',
    IntlDateFormatter::FULL,
    IntlDateFormatter::FULL,
    'Asia/Tehran',
    IntlDateFormatter::TRADITIONAL,
    'EEEE d MMMM yyyy HH:mm' // as ISO_8601
);

echo datefmt_format($fmt, time()) . "\n"; // // پنجشنبه ۱۰ اردیبهشت ۱۳۹۴ ۱۲:۱۲

All of them implement icu library that process datetime based on locale and calendars: http://userguide.icu-project.org/datetime/calendar

Debian dev package: https://packages.debian.org/sid/libicu-dev

[iamkun]

I see. Seems not a widely used feature. If I am wrong, please let me know.

We might could add features like this into a plugin, not our core module.

[mhf-ir]

Base on icu data first calendar system on: https://github.com/unicode-cldr/cldr-core/blob/218129a0ead6f82b1b7e4c146e4264f3b475c303/supplemental/calendarPreferenceData.json

Afghanistan 37 million people use persian Iran 82 million people use persian Saudi Arabia 33 million people use islamic-umalqura Thailand 69 million people use buddhist. and other countries has another calendars systems. this population about 220 million people around world for the first different calendar system.

Also for multiple calendar system also: Japanese use second calendar japanese and South Korea use dangi and etc...

So for the library for used widely on many applications why we dont ignore many places in world ?

I don't get it, why world think we have 1 language 1 calendar 1 text direction ... We need movement for embrace whole world data process. JavaScript implement I18n so late but good, and many developers, such as UI/UX developers need to consider the I18n, l10n.

[behnoodk]

We might could add features like this into a plugin, not our core module.

It's a good idea. Moment supports Persian calendar through a plugin. @iamkun is there an established way to write a plugin for dayjs? How one may go about writing a plugin for dayjs? I couldn't find anything in the docs.

[mhf-ir]

It's good to have plugin, but in many framework libraries developer path the datatime processing into main process. but with simplest design of datetime based on i18n and l10n, actually we cant see any libraries with good design.

We need a simple repo to tell whole developers that we exist with non-Georgian, no LTR direction.

In most libraries RTL, i18n, l10n is patch or 3rd party. bootstrap 3 not have rtl also v4 not implemented ... if developer consider rtl exist it will be simple config. https://github.com/twbs/bootstrap/issues/19545

[iamkun]

@behnoodk We are doing this. May be will release in next minor release. Won't too long!

[iamkun]

I'll close this issue since it's been a while, and there is already a plugin supports jalili calender in github. Feel free to reopen if you have updates on this

[mhf-ir]

https://mhf-ir.github.io/i18nplease/

[theMasix]

https://github.com/alibaba-aero/jalaliday This plugin solves the problem.

[Tal500]

https://github.com/alibaba-aero/jalaliday This plugin solves the problem.

This only solves the problem for a very specific calender, and the solution there is using many non-standards hacks!

I'll close this issue since it's been a while, and there is already a plugin supports jalili calender in github. Feel free to reopen if you have updates on this

TD.LR: Please re-open this issue again.

I seek specifically for support for the Hebrew calendar, but I can suggest how it "works" and a simple design for supporting new calenders (maybe as plugins, but need API for this!).

First, as you all know here, dates in computers are represented by the time diff from epoch, and not in a Gregorian format.

All calenders, as far as I know, work the same way - using three number - year + month + day. (I'm ignoring now the start of the week issue) Each year has an amount of months (not constant, unlike the Gregorian calender for example!!!!), and each month has an amount of days (not constant, similarly to the Gregorian calendar). Moreover, months are days could be displayed in many ways - for example in the Gregorian calender, months are displayed either by name or by a number, and in Hebrew calender days and years are represented only by letters in Gematria. For calculating the date, one need to convert the time from epoch to the format of year/month/day and vice-versa. Usually for calenders there are formulas to convert epoch time to year/moth/day representation that are faster than just the slow computation based on counting how many months were at each year, how many days were in a month and so on...

I suggest the following plugin API for this library to have consisting a simple API allowing the user to specify:

• Calender name
• Conversion functions from epoch time to year/month/day representation only in integers and vice-versa.
• Conversion functions from epoch time to year/month/day representation in many display formats and vice-versa.
• Functions which display the year or the month or the day from integer to display (there could be many display formats, for example in the Gregorian calender you could display moths either by names or by integers), and vice-versa.

I also suggest to let each calender-specific plugin designers a total control about string translations(i18n), because the rules are not consistent.

I personally think that my suggestion is pretty generic but need only relatively simple changes to the API. What do you think? I suggest to start an experimental API and let the community to test it with their favorite calenders.

[SalahAdDin]

https://github.com/alibaba-aero/jalaliday This plugin solves the problem.

This only solves the problem for a very specific calendar, and the solution there is using many non-standard hacks!

I'll close this issue since it's been a while, and there is already a plugin that supports the Jalili calendar in Github. Feel free to reopen if you have updates on this

TD.LR: Please re-open this issue again.

I seek specifically for support for the Hebrew calendar, but I can suggest how it "works" and a simple design for supporting new calenders (maybe as plugins, but need API for this!).

First, as you all know here, dates in computers are represented by the time diff from the epoch, and not in a Gregorian format.

All calendars, as far as I know, work the same way - using three numbers - year + month + day. (I'm ignoring now the start of the week issue) Each year has a number of months (not constant, unlike the Gregorian calendar for example!!!!), and each month has a number of days (not constant, similar to the Gregorian calendar). Moreover, months are days that could be displayed in many ways - for example in the Gregorian calendar, months are displayed either by name or by a number and in the Hebrew calendar days and years are represented only by letters in Gematria. For calculating the date, one needs to convert the time from epoch to the format of year/month/day and vice-versa. Usually, for calendars, there are formulas to convert epoch time to year/month/day representation that is faster than just the slow computation based on counting how many months were in each year, how many days were in a month, and so on...

I suggest the following plugin API for this library to have to consist a simple API allowing the user to specify:

* Calender name

* Conversion functions from epoch time to year/month/day representation **only in integers** and vice-versa.

* Conversion functions from epoch time to year/month/day representation **in many display formats** and vice-versa.

* Functions that display the year or the month or the day from integer to display (there could be many display formats, for example in the Gregorian calendar you could display moths either by names or by integers), and vice-versa.

I also suggest letting each calender-specific plugin designer total control over string translations(i18n), because the rules are not consistent.

I personally think that my suggestion is pretty generic but need only relatively simple changes to the API. What do you think? I suggest starting an experimental API and letting the community test it with their favorite calendars.

Totally agree with this.

[SalahAdDin]

@mhf-ir can you reopen this issue? there is no official support for any other calendar than the Georgian one.

[amirhmoradi]

Hi dear @mhf-ir @Tal500 @SalahAdDin @behnoodk @iamkun , I have created a new dayjs plugin that allows managing multiple calendar systems.

I have already implemented the Persian calendar system and I am working on other calendar systems now. It does correct conversions to and from persian calendar, and is compatible with .tz, .utc and other functions.

The current plugin is stable and tested (more tests/bug reports/feature requests are WELCOME).

My plugin uses a standard dayjs plugin development approach and I tried to avoid all hacks and patch work. Please test it and open issues or PRs, everything is in the documentation file README.md.

https://github.com/calidy-com/dayjs-calendarsystems