ICU-20178 Initial checkin of Tibetan Calendar

[dyrroth-11]

This PR attempts to add support for the Tibetan calendar (Phagpha & Tsurphu) in ICU4C.

The Tibetan calendar is a lunisolar calendar and the typical sequence of days of the month in a lunisolar calendar is not a simple sequence of numbers, but instead it has leap days as well as omitted days. A major challenge was to deal with leap days because the current calendar class of ICU4C does not have a leap day field. I've used a +64 encoding for storing leap day and leap month info that do not require any additional calendar field.

Checklist

• [x] Required: Issue filed: https://unicode-org.atlassian.net/browse/ICU-20178
• [x] Required: The PR title must be prefixed with a JIRA Issue number.
• [x] Required: The PR description must include the link to the Jira Issue, for example by completing the URL in the first checklist item
• [x] Required: Each commit message must be prefixed with a JIRA Issue number.
• [x] Issue accepted (done by Technical Committee after discussion)
• [x] Tests included, if applicable
• [ ] API docs and/or User Guide docs changed or added, if applicable

[CLAassistant]

All committers have signed the CLA.

[markusicu]

@Manishearth FYI

[pedberg-icu]

Can you provide a link here to a site with a detailed description of the desired behavior of these calendars? I think there were some related links in the recent CLDR tickets about Tibetan calendar and other issues...

[eroux]

@pedberg the reference we used is "Kalacakra and the Tibetan Calendar" by Edward Henning. He also has a website that describes many aspects of the calendar: http://kalacakra.org/ .

There are more simple modern mathematical description in:

• https://arxiv.org/pdf/1401.6285.pdf
• Dershowitz & Reingold, Calendrical Calculations, 2008 (perhaps the easiest)

I have a few slides presenting the intercalation patterns at the end of the presentation I prepared for our meeting:

https://docs.google.com/presentation/d/1VKTQT_UyM4CYtuS52iQ4HebsprEqI3UKH2GYsev8PGc/edit#slide=id.gde1b0ab881_0_26

I can also prepare a shorter description of the main features of the calendar if that helps... what would be a good format?

[eroux]

Note that this PR presupposes https://github.com/unicode-org/cldr/pull/1280 and we will also provide another CLDR PR later so that these new calendars can be displayed properly. I thought perhaps in a first step we could get feedback on this PR before we do the next one, so that we're sure we're on tracks... wdyt?

[eroux]

@FrankYFTang thanks a lot for your review! I'm traveling but I'll make sure the PR is updated in a few weeks

[FrankYFTang]

ok, after more code review, I think the two different calendar only differ in the following constants

1. type "tibetan" vs "tibetan-tsurphu"

2. 5 constant (4 double and 1 int32_t) used in the calculation: a0, m0, s0, and alpha as double, and year0 as int32_t How about

3. we define a TibetanCalendar class and a TibetanTsurphuCalendar class. subclassing from TibetanCalendar.

4. the getType() of TibetanCalendar always return "tibetan" and we have an override getType() of TibetanTsurphuCalendar always return "tibetan-tsurphu".

5. in TibetanCalendar we add 5 protected getters

protected: 
  virtual double getAlpha() const;
  virtual double getM0() const;
  virtual double getA0() const;
  virtual double getS0() const;
  virtual int32_t getYear0() const;

and the implementation simply return PHUGPA_ALPHA, PHUGPA_M0, PHUGPA_A0, PHUGPA_S0, and PHUGPA_YEAR0 4. in TibetanTsurphuCalendar, we override these protected function and return TSURPHU_ALPHA, TSURPHU_M0, TSURPHU_A0, TSURPHU_S0, and TSURPHU_YEAR0 5. Then the rest of the implementation could just call them to get the value and can share the code in TibetanCalendar.

[eroux]

@FrankYFTang thank you so much for your very thorough review! I'll make time for this in the next few weeks

[FrankYFTang]

Close this one, in favor of https://github.com/unicode-org/icu/pull/2296