Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Chinese Holiday #43

Open
fanste opened this issue Mar 8, 2017 · 10 comments
Open

Chinese Holiday #43

fanste opened this issue Mar 8, 2017 · 10 comments

Comments

@fanste
Copy link
Contributor

fanste commented Mar 8, 2017

Is there a chance to get a chinese holiday XML file? Is the library even prepared to calculate those holidays?

Thanks.

@svendiedrichsen
Copy link
Owner

svendiedrichsen commented Mar 8, 2017

There is a branch of jollyday from Soeren Strassfeld who tried to implement a chinese calendar. I haven't checked if he succeeded. Do you mind checking it? Come back any time an if it is ok I will try to merge it then.

https://github.com/soe78/jollyday

Cheers and thanks in advance.

@fanste
Copy link
Contributor Author

fanste commented Mar 14, 2017

I still hat no time to check the fork in my application, but the code doesn't look like it is completed.

I will come back as soon as I had the time to try it.

@soe78
Copy link

soe78 commented Nov 30, 2017

I'm very sorry I "ignored" Jollyday for almost 2 years after playing around with it and then coming back and find my name in an open issue.
Three things kept me from making a pull request.

  1. The calculations are based on the icu4j chinese calendar, so it would introduce another dependeny.
  2. I am still unsure about Qingming - is it just 15 days after spring equinox or is its celebration based on the solar term celestial longitude of 15°
  3. I did not implement "holiday swapping" for example if labour day is on a weekend, you will get an extra day of on monday. I'm also not clear if this is in the scope of jollyday
    I also ignored the special holidays for ethic minorities. As java 8 comes with an islamic calendar it should be easy to implement these (jollyday does already), but I hardly found information about the tibetan calendar.

@MenoData
Copy link

MenoData commented Dec 4, 2017

@soe78 My main problem with ICU4J is not that it forms another dependency but because its astronomical calculations are known to be not very precise. And this fact causes some chinese calendar dates in ICU4J to be wrong at least in historic times.

By the way, my hope that standard Java will ever realize this calendar is almost zero because it is not simple at all, requires strong astronomical background and has occasionally leap months which don't fit well in the java.time-calendar design (Chinese leap months require the SAME number as the foregoing month but this is not possible neither in the ICU4J-design nor in the new java.time.chrono-design). You seem to think that the islamic calendar of Java-8 is difficult, but it is basically just a data table of month lengths per year (always 12 months) so it was relatively easy to implement. The Chinese calendar is really in another league of complexity.

Anyway, I think I can implement the Chinese calendar in medium term (hopefully until spring 2018) because I have already done some important preparations, for example calculation of new moon and east asian months, see also an issue in my lib Time4J. After that, I can also imagine to contribute Chinese holidays to this project.

@svendiedrichsen
Copy link
Owner

svendiedrichsen commented Dec 4, 2017

@MenoData @soe78 A perfect implementation would be imho a JDK Chronology based one. Ideally as an contribution to the Threeten Project. This way a maximnum number of people would benefit from it.

@MenoData
Copy link

MenoData commented Dec 4, 2017

@svendiedrichsen Unfortunately the calendar design of JDK (java.time.chrono) is not perfect. It is mainly designed for calendars with regular year-month-day-scheme and was never tested or discussed in more depth for calendars with different structures (calendar experts for Hebrew or Chinese were practically not involved).

So I fear that any hackish workaround in Threeten-Extra will also be broken or insufficient in several details (like now the i18n-features of Ethiopian calendar [to be fair, here not relevant for Jollyday] or the algorithmic limitations of actual JDK-8-HijrahCalendar - only Umalqura is offered [this is relevant for Jollyday]).

@MenoData
Copy link

MenoData commented Dec 4, 2017

If a java.time.chrono.ChineseChronology is ever to be happen then it must be an Oracle project, not in Threeten-Extra because otherwise it would not be possible to parse or format any real Chinese date due to some special features around leap months or year representations (year of the rat etc.). This task requires deeper changes to JDK-code which is not in the scope of Threeten-Extra.

But the good news is, my lib Time4J would take into account all aspects of a Chinese calendar in the future, including wide formatting and parsing capabilities in many languages.

@svendiedrichsen
Copy link
Owner

Looking forward to hearing from you.

@fanste
Copy link
Contributor Author

fanste commented Jun 1, 2018

@MenoData as I've seen you have completed your work on the chinese calendar part in your lib Time4J. Could you tell us if and when your time allows you to contribute Chinese holidays to jolliday?

@MenoData
Copy link

MenoData commented Jun 5, 2018

@fanste Yes, the Chinese calendar part of Time4J is now finished and ready to use. If we only speak about Java-8 then nothing will prevent a new pull request.

But some few things are still to do in context of modular Java-9 and OSGi. I hope to find some time for the necessary adjustments soon (mainly on the area of resource loading). Some work has already been done, for example automatic module names. These issues are similar to the obstacles with the combination of Jollyday and Java-9 (indirectly via the actual dependency on Threeten-Extra).

MenoData added a commit to MenoData/jollyday that referenced this issue Dec 23, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants