Implement the Hebrew calendar

[GoogleCodeExporter]

I expect this will not be done soon, but I would like it on the future road map 
please.

https://en.wikipedia.org/wiki/Hebrew_calendar

Thanks.

Original issue reported on code.google.com by mj1856 on 2 Aug 2013 at 6:24

[GoogleCodeExporter]

Sure. Just a few words of warning though:

- Until we do CLDR integration, month names for text handling are based on the 
culture you provide rather than the calendar system
- All our calendars assume that days start at midnight, rather than sunset, and 
with the "normal" hours/minutes/seconds... we'd just be doing the 
year/month/day calculations

Is that still useful, or would you really need a fuller solution?

Original comment by jonathan.skeet on 2 Aug 2013 at 6:33

[GoogleCodeExporter]

I can see that the usage might have to be limited to our LocalDate type.  If 
nothing else, being able to convert a LocalDate betweeen Hebrew and ISO 
calendars would be useful.  So would text formatting and parsing of Hebrew 
dates.

It *might* be possible to do something for fractions of a day, as there is some 
concept of "halakim".  But I'm not sure if our LocalTime type is appropriate or 
not.

I don't think other types that are more precise (such as Instant) would have 
any meaning in this calendar.

I am in no way familiar with it personally, but I do work with a lot of 
Israelis.  My understanding is that they use the Gregorian calendar in business 
and day-to-day life but certain formal legal and religious affairs are 
presented in Hebrew dates.  So it would be nice to have, but would probably be 
used more for display than for calculation. 

Original comment by mj1856 on 2 Aug 2013 at 7:26

[GoogleCodeExporter]

We can't limit usage to just LocalDate - it would just be a CalendarSystem. We 
can give details of limitations, of course, and *suggest* that developers don't 
use it with LocalDateTime etc.

Original comment by jonathan.skeet on 2 Aug 2013 at 10:01

[GoogleCodeExporter]

Linking these to the issue for later reference:

http://www.fourmilab.ch/documents/calendar#hebrew

http://en.wikipedia.org/wiki/Hebrew_calendar

Original comment by mj1856 on 15 Aug 2013 at 2:38

[GoogleCodeExporter]

Original comment by malcolm.rowe on 19 Aug 2013 at 9:30

• Changed state: Accepted
• Added labels: Type-Enhancement, Milestone-unscheduled

[GoogleCodeExporter]

I'm making some progress on this, but it's incredibly complicated.

It's useful to have a source of reference molads - one rather later than the 
molad tohu - and this page has some for recent times: 
http://www.chabad.org/library/article_cdo/aid/216238/jewish/Molad-Times.htm

That should be enough to validate that whatever calculations I come up with 
agree with the .NET Hebrew calendar.

Unfortunately applying the calculations backwards in time may prove beyond my 
wit, but if I can get them going forwards from ~2009 Gregorian, I can then try 
to apply them to the molad tohu and see if it all links up.

In practice, I don't anticipate actually computing the various month lengths 
etc on the fly: we'll have a lookup table. We may *generate* that from 
computations from the molad tohu when the calendar is first used... or we may 
just embed a hard-coded table.

Original comment by jonathan.skeet on 21 Nov 2013 at 4:54

[GoogleCodeExporter]

Thanks for looking at it.  Alternate calendars make my head hurt!  I think this 
will be  a good addition, opening up some use cases that are hard to do today 
in .net.

But it is not much more than a passing curiosity for me personally, so please 
don't feel any pressure to complete.

Original comment by mj1856 on 22 Nov 2013 at 10:56

[GoogleCodeExporter]

The algorithm in Calendrical Calculations would be ideal for this, but the 
license is too restrictive.

Fortunately, there's an older version of the authors' work as a public domain 
paper:
http://www.cs.tau.ac.il/~nachumd/papers/cc-paper.pdf

We can use that for the Hebrew calendar, but the other calendars in Calendrical 
Calculations would still have to be implemented separately.

Original comment by jonathan.skeet on 23 Feb 2014 at 5:49

[GoogleCodeExporter]

Now making very significant progress.

I suspect that we should regard this as "experimental" for 1.3, and *not* focus 
on text parsing and formatting. It becomes a pain as the name of the month 
depends on the year as well as the month itself, introducing all kinds of 
headaches. Also, period calculations are "interesting" when there's a leap 
month in the middle of the year - you can end up adding a year, changing month 
number but not changing actual month.

Anyway, we can definitely get *something* done by 1.3.

Original comment by jonathan.skeet on 13 Apr 2014 at 8:06

• Added labels: Milestone-1.3.0
• Removed labels: Milestone-unscheduled

[GoogleCodeExporter]

Okay, I think this is now done in terms of *coding* as far as I'd like to 
implement it in 1.3.

We support both month numbering systems (civil and ecclesiastical) and 
reasonable calendrical operations - although there can be some 
potentially-unexpected behaviour when calling SetYear and using the civil 
calendar... the month *number* can change, even if the month *name* doesn't.

Text handling should be fine when using numbers, but parsing with month *names* 
is odd to say the least, again because the name of a particular month number 
changes based on the year. The only way of getting the proper Hebrew month 
names is to create a Hebrew CultureInfo *and* set the BCL calendar system to 
Hebrew anyway, so I think it's reasonable to punt this to post-1.3. (I'd like 
to see if the English versions of the Hebrew month names are in CLDR, which 
will make this much simpler to test, from an English-speaking-developer 
perspective.)

Leaving open right now as I think we need more documentation around the 
limitations, but I'll try to get that done very soon.

Original comment by jonathan.skeet on 19 Apr 2014 at 10:43

• Changed state: Started

[GoogleCodeExporter]

Marking as fixed now that I've added some documentation - I've added issue 279 
for the fact that we don't support month names.

Original comment by jonathan.skeet on 19 Apr 2014 at 5:18

[GoogleCodeExporter]

Original comment by jonathan.skeet on 19 Apr 2014 at 5:18

• Changed state: Fixed