incorrect parsing using the Japanese calendar

[blq]

incorrect parsing using the Japanese calendar

[lifewithcats]

Changing "eras" property like following made it work fine:
{ "name": "平成", "start": new Date("1989/1/8").getTime(), "offset": 1988 },
{ "name": "昭和", "start": new Date("1926/12/25").getTime(), "offset": 1925 },
{ "name": "大正", "start": new Date("1912/7/30").getTime(), "offset": 1911 },
{ "name": "明治", "start": new Date("1968/9/8").getTime(), "offset": 1867 }

[blq]

seems to work, thanks!

[rdworth]

A different fix is needed as this one is not compatible with the specification for eras. See jquery.global.js lines 429-435

            eras: [
                // eras in reverse chronological order.
                // name: the name of the era in this culture (e.g. A.D., C.E.)
                // start: when the era starts in ticks (gregorian, gmt), null if it is the earliest supported era.
                // offset: offset in years from gregorian calendar
                { "name": "A.D.", "start": null, "offset": 0 }
            ],

[rdworth]

Also, see http://www.i18nguy.com/l10n/emperor-date.html the start of 明治 is 1868/9/8 not 1968/9/8

[lifewithcats]

Thank you for the indications.

[lifewithcats]

Here's correct values:
{ "name": "平成", "start": new Date("1989/1/8").getTime(), "offset": 1988 },
{ "name": "昭和", "start": new Date("1926/12/25").getTime(), "offset": 1925 },
{ "name": "大正", "start": new Date("1912/7/30").getTime(), "offset": 1911 },
{ "name": "明治", "start": new Date("1868/9/8").getTime(), "offset": 1867 },
{ "name": "西暦 '", "start": null, "offset": 0 }

[rdworth]

Thanks for your help. Next step is a QUnit test (see /tests/ folder) that fails with the current values and passes with the new values. There should be at least one test for each era.

[lifewithcats]

Thank you again for instruction.
But testing format and parse date part (test/parse.js lines 43-49) is not complete...

[rxaviers]

Globalize 1.x doesn't support Japanese calendar (regression). If you need such support, please weigh in #320. I'm closing this issue in favor of #320 to help focus our efforts. Also, note the new implementation is going to use CLDR data and potentially new code as well.