Как конвертировать Григорианский в китайский лунный календарь?

Я хочу построить приложение для android, используя Greogorian календарь китайский лунный календарь.

Я не знаю как конвертировать из Грегорианского в китайском календаре. Как я могу это сделать?

7
android calendar java

2 ответов

вы можете попробовать: http://www.docjar.com/html/api/com/ibm/icu/util/ChineseCalendar.java.html

существует contructor:

public ChineseCalendar(Date date) ...

ссылки:

Doc:http://icu-project.org/apiref/icu4j/com/ibm/icu/util/ChineseCalendar.html

источник:http://site.icu-project.org/download

3

преобразование из григорианского в китайский

только что я выпустил новую версию Time4J (v4.35, но используйте Time4A - v3.40-2018b на Android), который поддерживает лунный календарь. Преобразование из григорианского в китайский лунно-солнечный календарь можно сделать прямо вперед:

PlainDate gregorian = PlainDate.nowInSystemTime(); // 2018-03-07
ChineseCalendar cc = gregorian.transform(ChineseCalendar.axis());
System.out.println(cc); // chinese[wu-xu(2018)-1-21]

документация китайского календаря также содержит примеры того, как форматировать или анализировать его во многих локализованных пути.

специальные требования к дизайну дисплея на Android

имейте также в виду, что китайский календарь содержит элементы, которые не существуют в григорианский календарь, например циклические годы, скачок месяцев или солнечное термины (обобщение наших астрономических сезонов). Time4J / A может отформатировать его, но он специфичен для календаря. Это актуально, если вы подумали об универсальном календаре которая должна быть универсально применима ко всем календарям. Вероятно, лучше сделать конкретный дисплей для китайского календаря на Android, чтобы другие важные сведения, такие как циклические годы в текстовой форме или солнечные термины, все еще могли отображаться.

сравнение с ICU4J

основные отличия:

  • API-стиль: ICU4J принял старый мир java.util.Calendar в то время как Time4J/a следует доменному подходу
  • неизменяемости функция (ICU4J-calendar-class не является неизменяемым в отличие от Time4J/A)
  • солнечные термины (ICU4J, похоже, не имеет никакой поддержки для этой функции)
  • точность (ICU4J использует астрономический модуль, основанный на книге Питера Даффета / Смита, в то время как Time4J/A в основном основан на работе Жана Мееуса)

в то время как некоторые люди все еще любят старомодный стиль ICU4J, я больше всего беспокоюсь о точности ICU4J. Как ссылка, вы можете наблюдать данные опубликовано Гонконг обсерватория на 2018 год. ICU4J отклоняется от данных Гонконга уже на 2018-11-07 (в течение целого месяца дата неверна на один день!). Доказательство, используя следующий код:

DateFormat df = 
    DateFormat.getDateInstance(
        DateFormat.FULL, 
        ULocale.forLanguageTag("en-u-ca-chinese"));
SimpleDateFormat sf = new SimpleDateFormat("yyyy-MM-dd");
sf.setTimeZone(TimeZone.getTimeZone("Asia/Shanghai"));

ChineseCalendar cc = new ChineseCalendar(78, 35, 0, 0, 1);
System.out.println(df.format(cc.getTime())); // Friday, First Month 1, 2018(wu-xu)

for (int i = 0; i < 13; i++) {
    cc.add(Calendar.MONTH, 1);
    System.out.print(df.format(cc.getTime()));
    System.out.println("=>" + sf.format(cc.getTime()));
}

выход (обратите внимание на строку в ноябре):

Saturday, Second Month 1, 2018(wu-xu)=>2018-03-17
Monday, Third Month 1, 2018(wu-xu)=>2018-04-16
Tuesday, Fourth Month 1, 2018(wu-xu)=>2018-05-15
Thursday, Fifth Month 1, 2018(wu-xu)=>2018-06-14
Friday, Sixth Month 1, 2018(wu-xu)=>2018-07-13
Saturday, Seventh Month 1, 2018(wu-xu)=>2018-08-11
Monday, Eighth Month 1, 2018(wu-xu)=>2018-09-10
Tuesday, Ninth Month 1, 2018(wu-xu)=>2018-10-09
Wednesday, Tenth Month 1, 2018(wu-xu)=>2018-11-07
Friday, Eleventh Month 1, 2018(wu-xu)=>2018-12-07
Sunday, Twelfth Month 1, 2018(wu-xu)=>2019-01-06
Tuesday, First Month 1, 2019(ji-hai)=>2019-02-05
Thursday, Second Month 1, 2019(ji-hai)=>2019-03-07

см. также старый нерешенная проблема на баг-трекере ICU4J, многие другие даты в будущем ошибочны. Конечно, астрономические расчеты не могут быть предсказаны строго для будущее, но первая дата, когда Time4J / a отклоняется от данных Гонконга, - это год 2057 (рассчитывается как только 37 секунд после местной полуночи), а не уже нынешний год 2018, как в ICU4J. Поэтому я бы не советовал ICU4J, пока они не исправили свой астрономический модуль и даже не могут быть правильными для фактического года.

чтобы быть реалистами в далеком будущем, мы не знаем, кто прав в 2057 году, и даже обсерватория Гонконга явно не уверена в этом дата:

если время новолуния (первый день лунного месяца) или солнечный срок близится полночь, даты соответствующего лунного месяца или солнечного срок в "таблице пересчета" может иметь расхождение в один день. Такие ситуация произойдет на новолуниях 28 сентября 2057 года [...]

1