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

Implement the Hebrew calendar #238

GoogleCodeExporter opened this issue Mar 15, 2015 · 12 comments

Implement the Hebrew calendar #238

GoogleCodeExporter opened this issue Mar 15, 2015 · 12 comments


Copy link

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


Original issue reported on by mj1856 on 2 Aug 2013 at 6:24

Copy link

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

Copy link

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 

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 

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

Copy link

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

Copy link

Linking these to the issue for later reference:

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

Copy link

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

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

Copy link

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:

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

Copy link

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

Copy link

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 

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

Copy link

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

Copy link

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 

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

Copy link

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

Copy link

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

  • Changed state: Fixed

@malcolmr malcolmr modified the milestone: 1.3.0 Mar 15, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

2 participants