Add support for non-Gregorian calendars #447

Open
wants to merge 62 commits into
from

Projects

None yet

9 participants

@dwachss
dwachss commented May 8, 2015

As discussed in globalizejs/globalize#320 , this creates a generalized date class and allows for the use of non-gregorian calendars. This is more of a proof-of concept; only Gregorian dates are implemented but other calendar algorithms could be added to Globalize.calendars.

Some thoughts:

Gdate should be an independent class; having calendars in Globalize makes the dependency graph circular (core.js depends on parse.js which depends on core.js for the calendar algorithms).

start-of.js is ugly; it has both the date and Gdate parameters, which must refer to the same date. That ought to be fixed.

I'm getting an error with the functional tests:

    .dateFormatter( pattern ) - should return a formatter
    Actual: null
    Expected: undefined
    Error: E_MISSING_CLDR: Missing required CLDR content
    'main/en/dates/calendars/gregorian/dateTimeFormats/availableFormats/dhms'.

But that looks like a problem with the cldr data.

I'm also getting errors from commitplease, but I don't know how to correct the messages on old commits.

@jquerybot jquerybot added the CLA: Valid label May 8, 2015
@dwachss dwachss date.js: bugfix RE in validateRequiredCldr
d8f6e02
@dwachss
dwachss commented May 8, 2015

The latest commit (@d8f6e02) now completes the grunt tasks without error.

dwachss added some commits May 8, 2015
@dwachss dwachss core.js: correct capitalization
dd508f8
@dwachss dwachss HebrewDate, IslamicDate: bugfix; forgot to set internal date
d3970e1
@dwachss dwachss HebrewDate.js: bugfix
3afc84c
@rxaviers rxaviers commented on an outdated diff May 11, 2015
@@ -28,6 +35,18 @@ function validateLikelySubtags( cldr ) {
cldr.get( "supplemental/likelySubtags" );
}
+function setLocale ( object, locale ){
+ var calendar;
+ validateParameterPresence( locale, "locale" );
+ validateParameterTypeLocale( locale, "locale" );
+ object.cldr = alwaysCldr( locale );
+ calendar = calendarsCalendarForLocale( object.cldr );
+ validateParameterType ( calendar, "calendar",
+ calendar in Globalize.calendars, "a defined calendar system" );
+ object.cldr.attributes.calendar = calendar;
+ validateLikelySubtags( object.cldr );
+}
@rxaviers
rxaviers May 11, 2015 Member

Please, revert this. Let's handle calender in the date module (not in core).

@rxaviers rxaviers commented on an outdated diff May 11, 2015
@@ -63,6 +63,7 @@ Globalize.prototype.dateFormatter = function( options ) {
cldr.on( "get", validateRequiredCldr );
pattern = dateExpandPattern( options, cldr );
properties = dateFormatProperties( pattern, cldr );
+ properties.calendar = Globalize.calendars[cldr.attributes.calendar];
@rxaviers
rxaviers May 11, 2015 Member

All properties must be set in dateFormatProperties. Let's set calendar in there as well.

@rxaviers
rxaviers May 11, 2015 Member

Inside dateFormatProperties, you won't have a reference for Globalize anymore. Instead of using Globalize.calendars as a hub for calendars, simply use something independent, e.g., calendar/calendars.js.

define([
    "./calendars/Gregorian-date",
    "./calendars/Hebrew-date",
    "./calendars/Islamic-date"
], function(calendarsGregorianDate, calendarsHebrewDate, calendarsIslamicDate) {

return {
  gregorian: calendarsGregorianDate,
  hebrew: calendarsHebrewDate,
  islamic: calendarsIslamicDate
};

});
@rxaviers rxaviers commented on an outdated diff May 11, 2015
@@ -104,6 +105,7 @@ Globalize.prototype.dateParser = function( options ) {
pattern = dateExpandPattern( options, cldr );
tokenizerProperties = dateTokenizerProperties( pattern, cldr );
parseProperties = dateParseProperties( cldr );
+ parseProperties.calendar = cldr.attributes.calendar;
@rxaviers
rxaviers May 11, 2015 Member

Analogous to above.

@rxaviers
Member

Great job so far!

Coding style... Your code uses arbitrary style. I'm not concerned with this right now. But, we'll have to fix all that at some point. Indentation, spaces, etc should follow http://contribute.jquery.org/style-guide/js/.

cldr.attributes... Please, do not change cldr.attributes (code). Instead, let's make something analogous to the numberingSystem (for numbers). In practice, this means instead of using
cldr.main("dates/calendars/{calendar}/dateTimeFormats"), use cldr.main([ "dates/calendars", calendar, "dateTimeFormats"), where calendar = fn( cldr ) (similar to this code).

@rxaviers rxaviers commented on an outdated diff May 11, 2015
src/date/last-day-of-month.js
@@ -7,8 +7,13 @@ define(function() {
*
* Return the last day of the given date's month
*/
-return function( date ) {
- return new Date( date.getFullYear(), date.getMonth() + 1, 0).getDate();
+return function( gdate ) {
+ // no choice but to move forward one at a time
+ for (var tomorrow = gdate.nextDate(1); tomorrow.getMonth() === gdate.getMonth();){
+ gdate = tomorrow;
+ tomorrow = gdate.nextDate(1);
+ }
+ return gdate.getDate();
@rxaviers
rxaviers May 11, 2015 Member

Can we move this manipulation into GDate?

@rxaviers rxaviers commented on an outdated diff May 11, 2015
src/date/parse.js
"../util/out-of-range"
-], function( dateIsLeapYear, dateLastDayOfMonth, datePatternRe, dateStartOf,
- createErrorUnsupportedFeature, dateSetMonth, outOfRange ) {
+], function( Globalize, datePatternRe, dateStartOf,
@rxaviers
rxaviers May 11, 2015 Member

We shouldn't need Globalize in here. Having calendars object in a different place (as commented above) will solve this.

@rxaviers rxaviers commented on an outdated diff May 11, 2015
src/date/parse.js
+ // rules. Why not today's date? The technical report
+ // http://www.unicode.org/reports/tr35/tr35-dates.html doesn't specify
+ // If month is not set but date is, use today's month
+
+ date = new Date();
+ gdate = new calendar( date );
+ ret = {
+ era: gdate.getEra(),
+ year: gdate.getYear(),
+ month: undefined,
+ date: undefined,
+ hour: date.getHours(),
+ minute: date.getMinutes(),
+ second: date.getSeconds(),
+ milliseconds: 0
+ };
@rxaviers
rxaviers May 11, 2015 Member

Can we keep each field in its own local variable (not a ret property), like the example below. Because, we're not taking any benefit from having it inside ret. In fact, ret. becomes repetitive below.

era = gdate.getEra();
year = ...
...
@rxaviers
rxaviers May 11, 2015 Member

Plus, local variables are better minified. For example, milliseconds becomes an arbitrary variable like a. In the other hand, ret.milliseconds can't be changed. It becomes something like a.milliseconds when minified.

@rxaviers rxaviers commented on an outdated diff May 11, 2015
src/date/parse.js
}
+ date = gdate.toDate();
+ date.setHours(ret.hour);
+ date.setMinutes(ret.minute);
+ date.setSeconds(ret.second);
+ date.setMilliseconds(ret.milliseconds);
@rxaviers
rxaviers May 11, 2015 Member

Can we reverse this logic? I mean keep handling time fields the way we were before and then setting the date fields of date by using setFns functions with gdate values.

@rxaviers rxaviers commented on an outdated diff May 11, 2015
src/date/parse.js
- date.setFullYear( date.getFullYear() * -1 + 1 );
+ if ( ret.month == null && ret.date == null && truncateAt.indexOf( YEAR ) !== -1) {
+ // year was defined but month was not
+ gdate = new calendar( dateStartOf ( date, "year", gdate ) );
+ ret.month = gdate.getMonth();
+ ret.date = gdate.getDate();
+ }
+ if ( ret.month == null ) {
+ ret.month = gdate.getMonth();
+ }
+ if ( ret.date == null && truncateAt.indexOf( MONTH ) !== -1) {
+ // month was defined but date was not
+ ret.date = 1; // gdate assumes 1 is the first date of the month
+ }
+ if ( ret.date == null ) {
+ ret.date = gdate.getDate();
@rxaviers
rxaviers May 11, 2015 Member

Please, what changed compared to how we handled this previously?

@rxaviers rxaviers commented on an outdated diff May 11, 2015
src/calendars/calendar-for-locale.js
+ }
+ return cal;
+ }
+
+ cal = cldr.get( [ "supplemental/calendarPreferenceData", cldr.attributes.region ] );
+ // It might be worth passing in a list of available calendars and returning
+ // the first one on both lists.
+ // But for now, just return the most preferred
+ if (cal) {
+ return cal.split( " " )[0];
+ }
+ // Return the default calendar
+ return "gregorian";
+};
+
+});
@rxaviers
rxaviers May 11, 2015 Member

The algorithm looks great for now, except for one thing: I don't plan to require calendarPreference supplemental data. If such supplemental data is loaded, great. Use it. Otherwise, simply pick gregorian. Therefore, we should include supplemental/calendarPreferenceData path as another skip-validation-paths here.

@rxaviers
Member

I left inline comments.

Variable names... There are a lot of abbreviated names, e.g., cal, d, m (especially in the gdate code). All variable names should use full words (names should be descriptive but not excessively so).

Third party code... If there is any code borrowed from different libraries, we must mention them. So, please let me know.

@rxaviers
Member

Thanks so far and just let me know on any questions.

@dwachss
dwachss commented May 11, 2015

Thanks for all the comments and code review. I'm out of town for the next week (new granddaughter!) but I will go through it all when I get back.

Sent from my iPad

On May 11, 2015, at 11:12 AM, Rafael Xavier de Souza notifications@github.com wrote:

Thanks so far and just let me know on any questions.


Reply to this email directly or view it on GitHub.

@rxaviers
Member

Congratulations and thanks for letting me know.

dwachss added some commits May 18, 2015
@dwachss dwachss Globalize: Incorporate @rxaviers suggestions
move calendar algorithms to Gdate from globalize
13373d7
@dwachss dwachss Globalize: remove dependency on calendar from testing fa36846
@dwachss dwachss Globalize: pass functional tests
00434ec
@dwachss
dwachss commented May 19, 2015

I think I've incorporated everything into the newest commit.
I'm happy to make stylistic changes to fit jQuery's needs; I figure that if it passed jscs it must be OK.

I changed the ".../{calendar}/..." CLDR traversing to use [..., calendar, ...] without using cldr.attributes, but I disagree on this. You created an elegant mechanism for incorporating information in cldr paths; why not use it?

I'm still not happy with the way Gdate is defined. It ends up internal to dist/globalize/date.js, so it can't be used outside (say with a datepicker widget), and the calendar constructors have to be included in parse.js, rather than somehow only loading the ones the user needs. I'm not sure what to do about that. I don't have any experience with AMD or bower to know how to make it its own module. Ideas would be appreciated.

dwachss added some commits May 19, 2015
@dwachss dwachss Islamic-date: bugfix
67dce92
@dwachss dwachss Islamic-date: bugfix
1b1bf50
@rxaviers
Member

For the record, reviewing your changes is on my TODO list. I may be able to give you a position by mid next week.

@rxaviers
Member

Just commenting to let you know I will need some more time to review.

@dwachss
dwachss commented May 31, 2015

No rush. I appreciate the time you're taking.

dwachss and others added some commits Jun 22, 2015
@dwachss dwachss GDate.js: fix whitespace
5abdd07
@dwachss dwachss GDate: bugfix
copy constructor no longer assumes original GDate uses the same calendar system
85d5bf3
@rxaviers @dwachss rxaviers Docs: Update information about CLDR JSON packages.
Fixes #428
aa38ecb
@rxaviers @dwachss rxaviers Docs: Amend information about CLDR JSON packages
Ref #428
eae0efe
@dwachss dwachss date: implement month-names 53c6014
@dwachss dwachss month-names: start tracking a924a98
@dwachss dwachss gdate: add unit tests a52e9af
@dwachss dwachss Gdate: tests pass jshint 4c23aa2
@dwachss dwachss test: add Hebrew calendar format and Islamic GDate testing dbd81f3
@dwachss dwachss testing: tokenizer-hebrew passes; parse-hebrew does not 39b45dd
@dwachss dwachss test: parse-hebrew passes unit tests 23fe0c9
@dwachss dwachss gdate: whitespace 75a7e37
@dwachss
dwachss commented Jul 28, 2015

I added unit tests for the Hebrew and Islamic calendars. I added the code to support the Chinese calendar with its multiple intercalated leap months, but I don't know enough about it to actually implement it so it can be tested.
I will work on that.

@rxaviers
Member

Quick comment about testing... ICU online page could be used for checks/comparison.

@dwachss
dwachss commented Jul 29, 2015

Thank you for that link.
What is the relationship between ICU and CLDR? They are not the same organization as far as I can tell; the CLDR documentation references what ICU does.

Sent from my iPod

On Jul 29, 2015, at 6:13 AM, Rafael Xavier de Souza notifications@github.com wrote:

Quick comment about testing... ICU online page could be used for checks/comparison.


Reply to this email directly or view it on GitHub.

@rxaviers
Member

ICU is an implementation (for C, C++ and Java) that uses CLDR (and that has actually originated CLDR).

@ashensis
ashensis commented Sep 6, 2015

It was considered to contribute Islamic/Hebrew calendar/date picker to JQuery.
it looks like a few steps had been done already in this direction, I mean calendar Hebrew-date and Islamic-date classes developed by Danny Wachsstock which apparently are meant to be included as integral part of Jquery.

I am wondering, whether these Hebrew-date and Islamic-date classes were intended to be coupled with JQuery date picker at the first palce.
Do they posses all auxiliary functions to make support for corresponding national date pickers (it seems to me that the answer to this question is negative, i do not see methods like 'firstDayOfMonth', ' 'firstDayOfWeek' etc.)
What was the purpose of developing these classes?
By the way, why these 2 calendar classes didn't find their way in Globalization 1.0 yet, what are the plans regarding these 2 classes.

The last question, could we contribute the corresponding date picker support to JQuery basing on extending aforementioned classes ?

@tomerm
tomerm commented Sep 6, 2015

First of all a couple of words on the expected functionality:

  1. From classes implementing calendaring logic we expect more or less standard API which should serve following purposes:
    a. Conversion of date represented as a string from one calendaring system to enother
    b. Support integration of calendaring logic into JQuery date picker - https://jqueryui.com/datepicker/
  2. From date picker (https://jqueryui.com/datepicker/) side we expect ability to show the date inside date picker (both input field and rectangular area on which usually one month of the calendar is graphically displayed) based on different calendaring systems (type of calendar [Thai, Islamic, Hebrew etc.] can be probably passed as a parameter to date picker widget during creation / initialization.

Second, our intention is to understand the stage of current discussion. From #320 it is clear that there is an intention to support non Gregorian calendars. It is less clear why this specific pull request has not been integrated yet into Globalize JQuery package. Are there any reservations related to submitted code ? What is missing ?

Finally, already now it is clear that at the very least following items are missing in the current submission:
a. Integration of non Gregorian calendar logic into JQUery date picker
b. Support for Hebrew numerals in Hebrew calendar (https://en.wikipedia.org/wiki/Hebrew_numerals)
c. Additional types of non Gregorian calendars
We are willing to contribute those items and want to better understand if we should base our work on top of @dwachss contribution or develop everything from 0.

@rxaviers
Member

Hello @ashensis and @tomerm.

First of all thanks for your wiliness to contribute, which is very welcome, and sorry for my delayed answer. I suggest your contribution continues @dwachss work instead of beginning something from 0.

Some preliminary points for clarification:

  • The Globalize scope (in this particular subject) is about formatting dates from JavaScript (i.e., instance of Date()) into its corresponding localized String on any of the calendars we support, e.g., new Date() -> 'Monday, September 28, 2015 at 5:56:08 PM' (or equivalent in other locales and calendars), i.e., gregorian and hopefully soon non-gregorian calendars too. It's also about the reverse operation, i.e., parsing the localized String into JavaScript Date() instance.
  • The datepicker, i.e., the UI widget that renders the calendar and that manages user input is not part of Globalize. It's part of the jQuery UI and @scottgonzalez or @jzaefferer can guide you out here.

About this PR... All logic for calendrical calculations should be made by an independent library (currently living in this repository, but planned to live elsewhere), which we called GDate and its API is drafted here. Globalize is going to use this library (or any other library that provides the same API) for converting calendars when formatting or parsing dates.

I do not see methods like 'firstDayOfMonth', ' 'firstDayOfWeek' etc.

All calendrical calculations should be made by an independent library called GDate (see paragraph above).

Note though you can still use Globalize to either format or parse these fields. See http://www.unicode.org/reports/tr35/tr35-dates.html#Date_Field_Symbol_Table for the appropriate pattern that you could use for these. Another related doc https://github.com/jquery/globalize/blob/master/doc/api/date/date-formatter.md.

  1. From classes implementing calendaring logic we expect more or less standard API which should serve following purposes:
    a. Conversion of date represented as a string from one calendaring system to enother

The calendrical calculations library scope (GDate) is defined in the link mentioned above. It's not in the scope of GDate to parse Strings though. It was planned to be kept as simple as possible. It's core is calendrical calculations. The scope of parsing strings is of Globalize.

By the way, do you have a reference for "standard API" please?

It is less clear why this specific pull request has not been integrated yet into Globalize JQuery package. Are there any reservations related to submitted code ? What is missing ?

Excellent question. This PR is already working to format and to parse some non-greg calendars. But, it isn't complete. The next step is to finish elaborating the GDate API and have Globalize to transparently use either a lightweight embedded GDate for gregorian calendars or the external GDate for non-greg calendars.

b. Support for Hebrew numerals in Hebrew calendar (https://en.wikipedia.org/wiki/Hebrew_numerals)

Hebrew numbers are algorithmic, which isn't supported by Globalize. Globalize supports numeric digits only, e.g., latin, arabic, thai, bali, etc.

Would you like to contribute Globalize support for algorithmic numbers?

c. Additional types of non Gregorian calendars

Additional non greg calendars are welcome.

Did I answer to your questions? Please, just let me know if there's anything I can still answer. I hope Danny (@dwachss) can also weigh in.

PS: I'm skipping to answer the questions related to UI widget datepicker.

@tomerm
tomerm commented Oct 9, 2015

Hello Rafael,

Thanks a lot for your reply. We obviously don't want to start from 0
if there are some ongoing efforts. This is one the primary reason for all
the latest inquires discussed in this thread.

Would you like to contribute Globalize support for algorithmic numbers
(Hebrew numerals) ?
Yes, this is our intention. The logic is relatively simple and will be
submitted for review in Q4 2015

Additional non greg calendars are welcome.
@Mohamed & @Ramy please share your plans to add additional non Gregorian
calendars commonly used in Arabic speaking countries to Jquery. Thanks.

Best Regards,

Tomer Mahlin
Bidi Champion, Globalization Manager, GCoC
Bidi Development Lab

Phone: +972-2-6491784 | Mobile: +972-54-3368122 E-mail: tomerm@il.ibm.com

IBM R&D Labs
Malcha Technology Park
Jerusalem 96951
Israel

From: Rafael Xavier de Souza notifications@github.com
To: jquery/globalize globalize@noreply.github.com
Cc: Tomer Mahlin/Israel/IBM@IBMIL
Date: 28/09/2015 23:54
Subject: Re: [globalize] Add support for non-Gregorian calendars
(#447)

Hello @ashensis and @tomerm.
First of all thanks for your wiliness to contribute, which is very
welcome, and sorry for my delayed answer. I suggest your contribution
continues @dwachss work instead of beginning something from 0.
Some preliminary points for clarification:
The Globalize scope (in this particular subject) is about formatting dates
from JavaScript (i.e., instance of Date()) into its corresponding
localized String on any of the calendars we support, i.e., gregorian and
hopefully soon non-gregorian calendars too. It's also about the reverse
operation, i.e., parsing the localized String into JavaScript Date()
instance.
The datepicker, i.e., the UI widget that renders the calendar and that
manages user input is not part of Globalize. It's part of the jQuery UI
and @scottgonzalez or @jzaefferer can guide you out here.
About this PR... All logic for calendrical calculations should be made by
an independent library (currently living in this repository, but planned
to live elsewhere), which we called GDate and its API is drafted here.
Globalize is going to use this library (or any other library that provides
the same API) for converting calendars when formatting or parsing dates.
I do not see methods like 'firstDayOfMonth', ' 'firstDayOfWeek' etc.
All calendrical calculations should be made by an independent library
called GDate (see paragraph above).
Note though you can use Globalize for either to format or to parse these
fields. See
http://www.unicode.org/reports/tr35/tr35-dates.html#Date_Field_Symbol_Table
for the appropriate pattern that you could use for these. Another related
doc
https://github.com/jquery/globalize/blob/master/doc/api/date/date-formatter.md
.

  1.  From classes implementing calendaring logic we expect more or less 
    

standard API which should serve following purposes: a. Conversion of date
represented as a string from one calendaring system to enother
The calendrical calculations library scope (GDate) is defined in the link
mentioned above. It's not in the scope of GDate to parse Strings though.
It was planned to be kept as simple as possible. It's core is calendrical
calculations. The scope of parsing strings is of Globalize.
By the way, what's your reference for the mentioned "standard API" please?
It is less clear why this specific pull request has not been integrated
yet into Globalize JQuery package. Are there any reservations related to
submitted code ? What is missing ?
Excellent question. This PR is already working to format and to parse some
non-greg calendars. But, it isn't complete. The next step is to finish
elaborating the GDate API and have Globalize to transparently use either a
lightweight embedded GDate for gregorian calendars or the external GDate
for non-greg calendars.
b. Support for Hebrew numerals in Hebrew calendar (
https://en.wikipedia.org/wiki/Hebrew_numerals)
Hebrew numbers are algorithmic, which isn't supported by Globalize.
Globalize supports numeric digits only, e.g., latin, arabic, thai, bali,
etc.
Would you like to contribute Globalize support for algorithmic numbers?
c. Additional types of non Gregorian calendars
Additional non greg calendars are welcome.
Did I answer to your questions? Please, just let me know if there's
anything I can still answer. I hope Danny (@dwachss) can also weigh in.
PS: I'm skipping to answer the questions related to UI widget datepicker.

Reply to this email directly or view it on GitHub.

@rxaviers
Member

Excellent @tomerm, @Mohamed, and @Ramy. I'm looking forward to it. Please, just let me know if there's any input you need from me.

@ashensis

Hi Rafael.
Please look at new feature regarding Globalize support for algorithmic numbers that I got created:
#537

@dwachss
dwachss commented Oct 19, 2015

I've pushed a new commit that changes the interface for GDate to separate month (which is now a number, as rxaviers has been arguing for) and monthType, which is a string that will be undefined for most calendars, and "leap" for lunisolar leap months.
It became clear that this would be necessary when I tried to implement the Chinese calendar, The "monthType" parameter uses the terms from the CLDR monthPattern element ( http://www.unicode.org/reports/tr35/tr35-dates.html#monthPatterns_cyclicNameSets ).
See the updated GDate API gist at https://gist.github.com/dwachss/4f9a6c77c8feb8e2ad09

@eximiusdevelopment

Hi everyone,

I'm looking for support for the Persian calendar, is somebody already working on this by any chance?
Is there any chance that this branch (from dwachss) will be merged with master before the end of the year?

Regards,
Michael

@rxaviers
Member
rxaviers commented Dec 7, 2015

Hi @eximiusdevelopment, I don't think this is going to be ready and released by the end of the year, but this is an important feature that Globalize must support and all help is very much appreciated. Do you want to submit a PR extending this one with the support for Persian calendar?

Thanks.

@eximiusdevelopment

Hi Rafael,

That is ok, I have a branch but I'm new to this stuff so I have not yet created any tests for it. We have forked the branch of dwachss and added the Persian calendar. But will this branch be merged into master in the future? Because I depend on the Gdate implementation.

We are currently working together with an Iranian company to get the dates validated, because we have taken the logic from existing implementations (keithwood I think and JDate) but we want to make sure it is solid. When that is done we will send a PR.

Regards,
Michael

@dwachss
dwachss commented Dec 9, 2015

That's great. The more calendars we can get implemented the better. Is this the Solar Hejri calendar (https://en.wikipedia.org/wiki/Solar_Hijri_calendar) ? I am working on getting the astronomical calculations that are needed for all these calendars and I'd like to see what you have. Looking forward to your PR.Danny

On Wednesday, December 9, 2015 11:01 AM, eximiusdevelopment <notifications@github.com> wrote:

Hi Rafael,That is ok, I have a branch but I'm new to this stuff so I have not yet created any tests for it. We have forked the branch of dwachss and added the Persian calendar. But will this branch be merged into master in the future? Because I depend on the Gdate implementation.We are currently working together with an Iranian company to get the dates validated, because we have taken the logic from existing implementations (keithwood I think and JDate) but we want to make sure it is solid. When that is done we will send a PR.Regards,
Michael —
Reply to this email directly or view it on GitHub.

@eximiusdevelopment

Hi Danny,

First of all thank you for your initial code of the Gdate, without that code we would not be able to do this in a short time.
The calendar we are implementing is the Persian Jalali calendar (https://en.wikipedia.org/wiki/Jalali_calendar), which is used in Iran.

Regards,
Michael

From: Danny Wachsstock [mailto:notifications@github.com]
Sent: woensdag 9 december 2015 18:27
To: jquery/globalize globalize@noreply.github.com
Cc: Michael Beckers michael.beckers@objectway.com
Subject: Re: [globalize] Add support for non-Gregorian calendars (#447)

That's great. The more calendars we can get implemented the better. Is this the Solar Hejri calendar (https://en.wikipedia.org/wiki/Solar_Hijri_calendar) ? I am working on getting the astronomical calculations that are needed for all these calendars and I'd like to see what you have. Looking forward to your PR.Danny

On Wednesday, December 9, 2015 11:01 AM, eximiusdevelopment <notifications@github.commailto:notifications@github.com> wrote:

Hi Rafael,That is ok, I have a branch but I'm new to this stuff so I have not yet created any tests for it. We have forked the branch of dwachss and added the Persian calendar. But will this branch be merged into master in the future? Because I depend on the Gdate implementation.We are currently working together with an Iranian company to get the dates validated, because we have taken the logic from existing implementations (keithwood I think and JDate) but we want to make sure it is solid. When that is done we will send a PR.Regards,
Michael —
Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHubhttps://github.com/jquery/globalize/pull/447#issuecomment-163331880.

dwachss and others added some commits Jan 18, 2016
@dwachss dwachss gdate: merge master into 320-nongregorian db9e6bb
@dwachss dwachss astronomy.js: working on astronomy.js eef0f52
@rxaviers @dwachss rxaviers Gdate: correct commit messages b78f7c4
@dwachss dwachss Gdate: change constructor signature a408298
@dwachss dwachss GDate: new monthType model e0020dc
@dwachss dwachss astronomy.js: update comments dfe88c7
@dwachss dwachss astronomy: start working on new moon 4b8fab3
@dwachss dwachss astronomy: implement newMoon f10a690
@dwachss dwachss gdate: start Chinese-date.js 49669d8
@dwachss dwachss HebrewDate: bugfix in nextMonth d28220a
@dwachss dwachss ChineseDate: implement calendar algorithms c9388c0
@dwachss dwachss Chinese-date: pass jshint and jscs cd4b711
@dwachss dwachss Chinese-date: passes unit testing for calendar algorithm 8cdb39b
@dwachss dwachss Chinese-date: merge chinese calendar a840d47
@dwachss dwachss Chinese-date: remove console.error 51de5bb
@dwachss dwachss Gdate: correct white space 38b8a20
@dwachss dwachss Chinese-date: formatting passes unit tests 77dd6f8
@dwachss dwachss Chinese-date: allow for default parameters cd0287a
@dwachss dwachss Chinese-date: git add formatting tests 6d0446b
@dwachss dwachss Chinese-date: create parsing test 4a379eb
@dwachss dwachss astronomy: bug fix for UTC date 646d548
@dwachss dwachss Gdate: implement correct default initilization algorithm 3238149
@dwachss dwachss parse: bugfix 5e84a0a
@dwachss dwachss Chinese-date: pass parsing tests a8183de
@dwachss dwachss parse: change to use gdate exclusively c72f168
@dwachss dwachss Gdate: whitespace c37d442
@dwachss dwachss Gdate: correct intitializer f5e1c08
@dwachss dwachss GDate: default parameters pass testing c760bd3
@dwachss dwachss parse: remove unnecessary calendar setting in test 5a1b525
@rxaviers rxaviers commented on the diff Feb 11, 2016
src/date/tokenizer-properties.js
+ key = [
+ properties.calendar,
+ "months",
+ chr === "M" ? "format" : "stand-alone",
+ widths[ length - 3 ]
+ ].join( "/" );
+ properties[key] = dateMonthNames (
+ properties[key],
+ chr,
+ length,
+ properties.calendar,
+ cldr
+ );
+ } else {
+
+ // record the possible expansion for numeric months
@rxaviers
rxaviers Feb 11, 2016 Member

let's indent this according to the below.

@dwachss
dwachss Apr 6, 2016

I'm not sure what you mean.

@rxaviers rxaviers commented on the diff Feb 11, 2016
src/date/tokenizer.js
@@ -132,20 +133,48 @@ return function( value, numberParser, properties ) {
}
}
+ function monthNumber() {
+ var match, monthPatterns, reSource, type;
+ if ( length <= 2 ) {
+
+ // Unicode equivalent to \d+
@rxaviers
rxaviers Feb 11, 2016 Member

Let's indent this according to the below.

@dwachss
dwachss Apr 6, 2016

I'm not sure what you mean.

@rxaviers rxaviers and 1 other commented on an outdated diff Feb 11, 2016
test/unit/date/format.js
@@ -61,7 +61,7 @@ QUnit.assert.dateFormat = function( date, pattern, cldr, expected ) {
var pad,
numberFormatters = [],
properties = formatProperties( pattern, cldr );
-
+
@rxaviers
rxaviers Feb 11, 2016 Member

trailing space

@rxaviers rxaviers and 1 other commented on an outdated diff Feb 11, 2016
src/date/format-properties.js
chr === "M" ? "format" : "stand-alone",
widths[ length - 3 ]
]);
- } else {
+ }
+ properties.months[ chr ][ length ] = dateMonthNames(
+ properties.months[ chr ][ length ],
+ chr,
+ length,
+ properties.calendar,
+ cldr
+ );
+ if ( length <= 2 ) {
formatNumber = true;
}
@rxaviers
rxaviers Feb 11, 2016 Member

Can we revert length <= 2 as else.

@rxaviers
rxaviers Feb 11, 2016 Member

Is properties.months used now when formatNumber = true?

@dwachss
dwachss Apr 6, 2016

Unfortunately, the CLDR seems to specify that Chinese leap months get names like "6bis" or "06bis" even for "numeric" months. So properties.months is still needed.
The code initially sets it from CLDR, then uses dateMonthNames to update the names of the leap months.

I can move that final if back into the else.

@rxaviers rxaviers commented on an outdated diff Feb 11, 2016
src/date/format.js
@@ -97,7 +96,12 @@ return function( date, numberFormatters, properties ) {
// Quarter
case "Q":
case "q":
- ret = Math.ceil( ( date.getMonth() + 1 ) / 3 );
+
+ // There's no good way to do this with a generalized date.
@rxaviers
rxaviers Feb 11, 2016 Member

indentation

@rxaviers rxaviers and 1 other commented on an outdated diff Feb 11, 2016
src/date/format.js
@@ -97,7 +96,12 @@ return function( date, numberFormatters, properties ) {
// Quarter
case "Q":
case "q":
- ret = Math.ceil( ( date.getMonth() + 1 ) / 3 );
+
+ // There's no good way to do this with a generalized date.
+ // We have to approximate this, assuming a 12-month year and
+ // month numbers that correspond to the correct period of the year
+ ret = Math.min( parseInt( gdate.getMonth(), 10 ), 12 );
@rxaviers
rxaviers Feb 11, 2016 Member

Please, what's the return value of .getMonth() is it a string? Where does this string come from? I guess this comes from CLDR (the key of months object). Just confirming. Is this always a digit?

@dwachss
dwachss Apr 6, 2016

getMonth returns a number, so the parseInt is a bug. I'll remove it.

@rxaviers rxaviers commented on the diff Feb 11, 2016
src/date/month-names.js
+ * Name of the calendar system (e.g. "Gregorian", "Islamic")
+ *
+ * @cldr [Cldr instance].
+ *
+ * Returns a modified months array to include leap months in a format that allows for easier parsing
+ * and formatting, and works with GDate.
+ *
+ */
+return function( months, type, length, calendar, cldr ) {
+ var i, month, monthParts, monthPatterns, pattern;
+
+ if ( months ) {
+
+ // fastest (native) way to clone an object
+ months = JSON.parse( JSON.stringify( months ) );
+ }
@rxaviers
rxaviers Feb 11, 2016 Member

I'm wondering if we could avoid this.

@dwachss
dwachss Apr 6, 2016

are you talking about the clone? months is returned from cldr.main('dates/calendar') and is the actual data from the global CLDR object. I'm hesitant to change that directly; I don't know if any other part of the program relies on the month names in their original form.
You know cldr.js; if it's OK to modify it, we can drop that line.

@rxaviers rxaviers commented on the diff Feb 11, 2016
src/date/start-of.js
case "month":
- date.setDate( 1 );
- /* falls through */
case "day":
date.setHours( 0 );
/* falls through */
@rxaviers
rxaviers Feb 11, 2016 Member

Do we still need the switch?

@dwachss
dwachss Apr 6, 2016

I don't think we need the startOf function at all. I haven't eliminated it yet, but it should be.

dwachss added some commits Apr 6, 2016
@dwachss dwachss format.js: getMonth is now a number, not string 5c36ba4
@dwachss dwachss format.js: whitespace
5d1a40a
@Ashamandi

Hello @dwachss and @rxaviers , Could you please tell me what is done at supporting Hijri calender so far ? because I am interesting in contributing in this support, and as I see you don`t add it yet , Am I right?

@dwachss
dwachss commented Apr 21, 2016

Hijiri is the traditional Japanese calendar, right? I haven't done that, only Hebrew, Islamic and Chinese. Look at the gdate documentation and feel free to contribute.
The file astronomy.js has routines for new moons and solstices if you need that.
Danny

On Apr 21, 2016, at 9:11 AM, Ashamandi notifications@github.com wrote:

Hello @dwachss and @rxaviers , Could you please tell me what is done at supporting Hijri calender so far ? because I am interesting in contributing in this support, and as I see you don`t add it yet , Am I right?


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

@Ashamandi

Sorry but I mean by Hijri calendar the Islamic one which is a lunar calendar consisting of 12 months in a year of 354 or 355 days, Do you support it ??

@dwachss
dwachss commented Apr 22, 2016

I see. I have not implemented the astronomic Islamic calendar, but your help would be appreciated. As I said, the astronomy.js file has routines for new moons, but the details of the algorithm and adjusting for Mecca local time needs to be done.

Sent from my iPod

On Apr 21, 2016, at 11:18 AM, Ashamandi notifications@github.com wrote:

I go to /gdate/Islamic-date.js
I find it is about tabular calender
+// Islamic tabular calendar (http://en.wikipedia.org/wiki/Tabular_Islamic_calendar)

but I want to support muslium hijri calender
https://en.wikipedia.org/wiki/Islamic_calendar


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

@Ashamandi

@dwachss, Sorry for this misunderstanding, I found that you had already implemented what I was looking for so I would like to thank you for your great work,
and I have a question "When will this PR be ready and released so we can use this version of Globalize at Jquery-ui and create an islamic datepicker widget?" ... Thanks in advance

@scottgonzalez
Contributor

This will be released as part of jQuery UI 1.13.0, but we never assign or publicly forecast release dates.

@JSFOwner JSFOwner removed the CLA: Valid label Nov 2, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment