In TefilaRules, you have Mizmor Lesoda under a TODO. I need it now, so I implemented it like below.

public boolean isMizmorLesodaRecited(JewishCalendar jewishCalendar) {
    int holidayIndex = jewishCalendar.getYomTovIndex();
    return holidayIndex != JewishCalendar.EREV_YOM_KIPPUR && holidayIndex != JewishCalendar.EREV_PESACH && !jewishCalendar.isCholHamoedPesach();
}

You've introduced a method for handling a westward dip at specific altitude occurring after 12:00am (the Hooper Bay case). However, it doesn't handle the inverse case, an eastern rise that occurs before 12:00am.

TimeZone tz = TimeZone.getTimeZone('America/Godthab');   // (-03:00/-02:00)
GeoLocation location = new GeoLocation('Daneborg, Greenland', 74.2999996,-20.2420877, 0, tz);
AstronomicalCalendar ac = new AstronomicalCalendar(location);
ac.setAstronomicalCalculator = new NOAACalculator();
ac.getCalendar().set(2017, Calendar.April, 20);

Date result = ac.getSunriseOffsetByDegrees(94);  // equivalent to "2017-04-20T23:54:23-02:00"

A similar problem happens for the dates of April 17-19, but less extreme.

However, the solution you've used for adjusting the sunset date won't work as well here for 2 reasons:

1. If you calculate sunset for every sunrise, the calculation will recurse since sunset tries to call sunrise. You may be able to add some short circuiting to prevent this recursion.
2. There is no westward dip on that date at 94 degrees to calculate against :(. This is a larger general problem that you have with the sunset adjustment as well - there may not be a corresponding sunrise to check against.

I'd recommend an alternative approach for getting the date adjustment, if you're open to the idea.

To reproduce:

new JewishCalendar(new GregorianCalendar(1582, 9, 14))

Expected: 18 Tishrei 5343 (via Rosetta Calendar)
Got: 28 Tishrei 5343

SunTimesCalculator.getDayOfYear() calculates the day of the year for a specific date (here is an explanation how it works).
The code is originally from Kevin Boone. It doesn't appear that his code is online, but it can be downloaded here.

Line 117 is used to account for leap years:

int n3 = (1 + ((year - 4 * (year / 4) + 2) / 3));

However, this expression will always evaluate to 1.666667, which is truncated to 1 when assigned to an int. If this code is constant 1, it's not accounting for anything.

Kevin Boone writes that his algorithms are based on the ones in the US Naval Observatory's Almanac for Computers (1990). Looking there, it's evident that his code is missing something. The formula there has 2 extra places where the decimal is truncated, which in Java would be a cast to int:

int n3 = (1 + (int)((year - 4 * (int)(year / 4) + 2) / 3));

This code works correctly, because now n3 == 2 in non-leap years.

However, the Almanac also states that this formula will not work for centurial years not evenly divisible by 400, e.g. 1900 and 2100.
As a result, it would probably be better to replace this entire formula with Java's Calendar.get(Calendar.DAY_OF_YEAR), which serves the same purpose, as mentioned in the method's Javadoc.

First of all I must say this is a very impressive project.
regarding the API that is available at : https://wyrezmanim.herokuapp.com/api/zmanim

Is there a method to query multiple days from the API ?
In short - and for practical implementation of events or calendars - how can one get the NEXT Holiday for example or the NEXT Shabat or Yom Tov ?
The only method I can think of now is to do a query every day and then check the result - and if there is no "Parasha" or other name then query the next day and so on ..

Also - regarding that - is there a method in the API to get the NAMES of the days ( like for example are presented in the excel sheet exported from https://kosherjava.com/zmanim-project/zmanim-calendar-generator/

I have been working on adding
the "new" Artscroll/OzViHadar to your code
code is not ready to give you yet
code is at https://github.com/elazarrosenthal/zmanim/tree/newyerushalmi

But I noticed that the masechtosYerushalmiTransliterated array is out of order
Hebrew seems correct

web is info gotten from https://www.dafyomi.co.il/calendars/calendaryeru.htm
kz is KosherZmanim

In my sanity checks I noticed an error
fortunatly its only in the English names not the Hebrew

basicly sanhedrin and shavous are swapped

32 web Bava Basra kz Bava Basra בבא בתרא
33 web Shevuos kz Sanhedrin שבועות
34 web Makos kz Makos מכות
35 web Sanhedrin kz Shevuos סנהדרין

All the Bain Hashmashos functions are missing the second h in Hashmashos.

isShabbosMevorchim() should return false for the month of Tishrei.

I would like some input on the most ergonomic API surface for identifying a given zman.

I am developing KosherKotlin in tandem with BeautifulZmanim, and the need came up to indicate a user-readable description of each zman, and to filter/group together similar zmanim (e.g. all opinions for a given zman, all zmanim for a given opinion, etc.).

Right now, the function name and javadoc are the only info provided - which aren’t easily manipulated at runtime (not to mention the slight inconsistency in function naming which would make that even harder (e.g. alos60 vs. minchaGedola30Minutes)).

I assume that this is something that most user-facing apps had to do, which would imply that it is the responsibility of the library (instead of everyone making their own library on top of the library).

Ideally, the zman should also have some strongly-typed classification of how it was calculated (e.g. if(zman.opinion instanceof ZmanOpinion.FixedMinutes) print(zman.opinion.minutes)). This could be useful for translating the description into other languages (at the discretion of the library client), more in-depth user-facing explanations (ditto), grouping or filtering zmanim by their opinion/how they were calculated (not just what zman type they represent, such as latest shema), some simple data science/number-crunching, etc.

I have already wrapped all public APIs in a Zman object (defined below) with a ZmanType. I am wondering if this should be translated to Java and ported upstream?

Moshe Waisberg (author of Halachic Prayer Times Android) came up with 4 classifications for describing a zman to the user:

• “Day is $fixedMinutes minutes before sunrise / after sunset”
• “Day is $halachicMinutes minutes zmaniyos before sunrise / after sunset”
• “Day is $degrees˚ below sunrise / sunset”
• “According to $authority”
  It Seems like there is 1 more:
• Widely accepted or only opinion

So far, these use-cases lead me to the following abstraction:

• Every zman is one of two types:

• ValueBased: a zman that does not occur at a moment in time, but rather holds a duration/length of time (e.g. sha’ah zmanis)

• DateBased: a zman that has a momentOfOccurence.
  - I (re)discovered after I came up with the two types that there is already a Zman.java object with 4 properties:
  label: string
  duration: long
  zman: Date
  description: string,

• Every zman has a ZmanOpinion, one of (as in Moshe Waisberg’s model):

• FixedMinutes

• ZmaniyosMinutes

• Degrees

• Authority

• Unanimous

• Every zman has a ZmanType, (a user-friendly english and hebrew name is included here, but must be refactored into a localization mechanism). One of:

• SHAA_ZMANIS(“Halachic hour”, “שעה זמנית“),
  CHATZOS_HALAYLAH(“Halachic midnight”, “חצות הלילה“),
  MISHMAR(“Watch”, “משמר“), //synonymous with אשמורת
  ALOS(“Dawn”, “עלות השחר“),
  MISHEYAKIR(“Earliest Tallis and Teffillin (Misheyakir)“, ” (משיכיר) טלית ותפילין הכי מוקדם“), //pardon the modern Hebrew הכי vs. ביותר
  HANAITZ(“Sunrise”, “הנץ החמה“), //not NAITZ because the ה in Hanaitz is not a ה הידיעה (“the”), it is part of the participle (comparable to “הנצת“)
  CHATZOS_HAYOM(“Halachic midday”, “חצות היום“),
  MINCHA_GEDOLAH(“Greater Mincha”, “מנחה גדולה“), //any better translation? Just transliterate?
  MINCHA_KETANAH(“Lesser Mincha”, “מנחה קטנה“), //any better translation? Just transliterate?
  PLAG_HAMINCHA(“Plag Hamincha”, “פלג המנחה“), //should this be translated or transliterated?
  SHKIAH(“Sunset”, “שקיעה“),
  BAIN_HASHMASHOS(“Twilight”, “בין השמשות“),
  TZAIS(“Nightfall”, “צאת הכוכבים“),
  MOLAD(“New moon”, “מולד“), //accurate translation?

  //Related to rituals:
  SAMUCH_LEMINCHA_KETANA(“Close to Mincha Ketana”, “סמוך למנחה קטנה“), //see note on MINCHA_KETANAH
  SOF_ZMAN_KRIAS_SHEMA(“Latest time to say Shema”, “סוף זמן קריאת שמע“),
  SOF_ZMAN_TEFILLAH(“Latest time to daven Shacharis”, “סוף זמן תפילה“),
  SOF_ZMAN_ACHILAS_CHAMETZ(“Latest time to eat Chametz”, “סוף זמן אכילת חמץ“),
  SOF_ZMAN_BIUR_CHAMETZ(“Latest time to burn Chametz”, “סוף זמן ביעור חמץ“),
  EARLIEST_MINCHA(“Earliest Mincha”, “מנחה הכי מוקדם“),
  EARLIEST_KIDDUSH_LEVANA(“Earliest time to sanctify the moon”, “תחילת זמן קידוש לבנה“),
  SOF_ZMAN_KIDDUSH_LEVANA(“Latest time to sanctify the moon”, “סוף זמן קידוש לבנה“),
  CANDLE_LIGHTING(“Candle lighting”, “הדלקת נרות“)

The two edge-cases I saw in Moshe Waisberg’s classification and the possible solutions I see:

• what about when a zman has multiple originating authorities, or is known or held by several well-known authorities?
• Put the first author to formulate the calculation.
• Put all authors
• Put the most well known author(s)
• Put the most authoritative (e.g. I think R’ Moshe Feinstein is more authoritative for our generation than the Aruch Hashulchan)
• Put the first + most well known, in case it is known by an author other than the first one (e.g “Komarno” zmanim were sometimes from much older sources)
• or it is according to one authority’s understanding of another authority’s opinion? (e.g. , Rabeinu Tam as 72 minutes, Rabeinu Tam as 16.1 degrees, etc., or more complicated: R’Moshe’s understanding of the Magen Avraham as calculated using 18˚ to fixed local chatzos, 16.1˚, etc.)
• or it does not fit into the neat boxes defined by ZmanOpinion (e.g. sofZmanShmaAlos16Point1ToSunset)?
• A general description
• “Day starts at $startZman.description and ends at $endZman.description”
• A map of ZmanType to ZmanOpinion (possible split into start and end - or before or after?)
  - e.g. plagAlosToSunset:
  • day starts at alos16Point1Degrees
  • day ends at sunset,
  • sha’ah zmanis is calculated based on the opinion that the day is calculated from a alos16Point1Degrees of 16.1 degrees before sunrise to seaLevelSunset.
  • bainHashmashosRT13Point5MinutesBefore7Point083Degrees
    • Rabeinu tam
    • FixedMinutes(13.5)
    • Before: 7.083 degrees

What about when there is only one way to calculate a zman? What should the ZmanOpinion type be?
And should authority names be in Hebrew (e.g. sefer names), transliterated English (for languages that need ASCII), etc.? Should they be standardized across ports?
I am not sure which alternatives would be best, and would like input.

Looking at Class HebrewDateFormatter (while wondering if the class provides hebrew text for the schedule times, like Alos and Chatzos)

"the The list" The first "the" is redundant. This shows up twice.
ניצבים I believe there is no yud between the nun and tsadi.

Why is it פורים שושן and not the other way around? Same for "פורים שושן קטן". The English has it the other way around.

Formatting Bavli daf with Yerushalmi For matter

Working on adding some tests
I noticed the output formatting is not going to work in some tests ( one example blow others in same file)

I assume the assert part of the test is correct
but anyone looking at the output is going to see junk

src/test/java/com/kosherjava/zmanim/hebrewcalendar/YomiCalculatorTest.java

@Test
public void testCorrectDaf2() {
	JewishCalendar jewishCalendar = new JewishCalendar(5736, JewishDate.ELUL, 26);
	Daf daf = YomiCalculator.getDafYomiBavli(jewishCalendar);
	Assert.assertEquals(4, daf.getMasechtaNumber());
	Assert.assertEquals(14, daf.getDaf());
	System.out.println(hdf.formatDafYomiYerushalmi(jewishCalendar.getDafYomiBavli()));
}

I noticed the wrong time on an app I have whne comparing to another calendar

I put together this test

I think the java Calendar date math does not properly handle the Daylight savings time shift

Any Sugestions

package com.kosherjava.zmanim;

import com.kosherjava.zmanim.hebrewcalendar.JewishCalendar;

import java.util.Date;
import java.util.TimeZone;

public class TestMain {
static void printinfo(Date d) {

    JewishCalendar jc = new JewishCalendar(d);

    System.out.println(d);
    System.out.println(jc.getMolad());

    System.out.println(jc.getMoladAsDate());
    System.out.println(jc.getTchilasZmanKidushLevana3Days());
    System.out.println(jc.getTchilasZmanKidushLevana7Days());
    System.out.println(jc.getSofZmanKidushLevanaBetweenMoldos());
    System.out.println(jc.getSofZmanKidushLevana15Days());

}

public static void main(String[] args) {


    Date d = new Date();
    printinfo(d);
    System.out.println("=====================================");
    TimeZone.setDefault(TimeZone.getTimeZone("EST"));
    printinfo(d);


}

}

output
Sun Nov 21 18:49:34 EST 2021 <<<<<<<<<<<<<< note date run moled was before DST
1 Kislev, 5782
Thu Nov 04 18:34:46 EDT 2021
Sun Nov 07 17:34:46 EST 2021
Thu Nov 11 17:34:46 EST 2021
Fri Nov 19 12:56:48 EST 2021 <<<<<<<<<<<<< this 12 should be 11
Fri Nov 19 18:34:46 EST 2021

Sun Nov 21 18:49:34 EST 2021
1 Kislev, 5782
Thu Nov 04 17:34:46 EST 2021
Sun Nov 07 17:34:46 EST 2021
Thu Nov 11 17:34:46 EST 2021
Fri Nov 19 11:56:48 EST 2021 <<<<<<<<<<<<<<<<<< correct but does not match
Fri Nov 19 17:34:46 EST 2021

java.lang.IllegalArgumentException: A Jewish date earlier than 18 Teves, 3761 (1/1/1 Gregorian) can't be set. 3317, 13, 6 is invalid.

Replace implementation group: 'com.kosherjava', name: 'zmanim', version: '2.4.0' with implementation 'com.kosherjava:zmanim:2.4.0

If you look at this array, it contains an entry for Shushan Purim and Shushan Purim Katan.

However, it is spelled as "פורים שושן" and "פורים שושן קטן".

It should instead be "שושן פורים" and "שושן פורים קטן"

For convenience add a class or what-have-you to list all zmanim in Hebrew and English, including variants. The convenience is not having to type in multiple languages, especially in an environment that might get confusing with ltr and rtl at the same time. It also might help where someone does not know or forgets the correct term, or even when there is a disagreement over what the correct term is, such as נץ החמה vs הנץ החמה. Further, when someone does not care which term is used, a sensible default can be provided.

I fixed this as part of my pull request
Newyerushalmi Code to implement New Yerushalmi Yomi
#206
But incase you dont want to accept that request
Beawre that the current implimentation of YerushalmiYomiCalculator -> getDafYomiYerushalmi()
For Mesectas after the first will returen LastMisectah , LastMisectaMaxDaf+1
for the 1st daf of a new mesechta

The fix I did is on line 100 if (total <= BLATT_PER_MASSECTA[j]) {

replace <= with <

Anotherr fix would be to start the daf counter from not 0
but I did not try totest such a solution

Please find my port of your project to Go https://github.com/vlipovetskii/go-zmanim

public boolean isTishaBav() {
    int holidayIndex = getYomTovIndex();
    return holidayIndex == TISHA_BEAV;
}

public boolean isRoshChodesh() {
    int holidayIndex = getYomTovIndex();
    return holidayIndex == ROSH_CHODESH;
}

public boolean isYaalehVyavo() {
     return isRoshChodesh() || isCholHamoedPesach() || isCholHamoedSuccos();
}

public boolean isPurim() {
    int holidayIndex = getYomTovIndex();
    return holidayIndex == PURIM;
}

public boolean isAlHanissim() {
    return isPurim() || isChanukah();
}

All the above functions will work except isRoshChodesh(). For some reason, the const ROSH_CHODESH does not seem to be used. Why is that?

Whats the license of this library, i cant find one

I'm trying to use HebrewDateFormatter. Note, this is in vb.net via ikvm.

        Dim Formatter As New HebrewDateFormatter
        Dim Luach As New JewishCalendar
        Dim Yom As New JewishDate

        Formatter.setHebrewFormat(True)
        Debug.WriteLine(Yom)
        Debug.WriteLine(Formatter.format(Yom))
        Debug.WriteLine(Formatter.formatDayOfWeek(Yom))

        Debug.WriteLine(Luach)
        Debug.WriteLine(Formatter.formatParsha(Luach))
        Debug.WriteLine(Formatter.formatRoshChodesh(Luach))

The output is:

11 Iyar, 5781
י״א אייר תשפ״א
ששי
11 Iyar, 5781

So, the formatter for JewishDate seems to be working but not for JewishCalendar. I am trying to figure out what i am doing wrong. Is there another parameter for JewishCalendar that needs to be set before trying to format it?

can you add Shabbos shuva and hagadol and shira, chazon, and nachamu to the special Shabbasos?

Right now, in the current version of KosherJava, all the methods enumerated below rely on Shaah Zmanis (Temporal Hours) and by default they use the getShaahZmanisGra() method.

Here is a list of methods that use the getShaahZmanisGra() method:

getTzais72Zmanis();
getTzais90Zmanis();
getTzais96Zmanis();
getTzais120Zmanis();

getAlos72Zmanis();
getAlos90Zmanis();
getAlos96Zmanis();
getAlos120Zmanis();

However, if I want to use these methods with getShaahZmanisMga(), I would have to implement my own method. And so too for other shaah zmanis opinions.

Wouldn't it be better to add a parameter to ask which shaah zmanis to use? Something like this:

public Date getTzais72Zmanis(long shaahZmanis) {
long shaahZmanis = shaahZmanis;
if (shaahZmanis == Long.MIN_VALUE) {
return null;
}
return getTimeOffset(getElevationAdjustedSunset(), shaahZmanis * 1.2);
}

for all the methods above?

As of release JDK 5, this class has been supplemented with an equivalent class designed for use by a single thread, StringBuilder. The StringBuilder class should generally be used in preference to this one, as it supports all of the same operations but it is faster, as it performs no synchronization.

BS''D
Hi there! Thank you for writing this really useful library. I wanted to ask if you would consider releasing it under the Apache 2.0 or MIT license?

If we wanted to include your library in an Apache or other OSS licensed product, it might be difficult to do so.
Thanks!

Per hebcal/hebcal-js#47, there seems to be a miscalculation for when Midos starts.

https://github.com/KosherJava/zmanim/blob/master/src/net/sourceforge/zmanim/hebrewcalendar/YomiCalculator.java#L107
I believe the fix would as simple as changing this line to read blatt += 32;

if ((isErevYomTov() && (holidayIndex != HOSHANA_RABBA && (holidayIndex == CHOL_HAMOED_PESACH && getJewishDayOfMonth() != 20)))
Should be:
if ((isErevYomTov() && (holidayIndex != HOSHANA_RABBA || (holidayIndex == CHOL_HAMOED_PESACH && getJewishDayOfMonth() != 20)))

&& should have been ||

There is no way to translate the parsha returned from getUpcomingParshah API.
formatParsha uses internally the old getParsha API what returns JewishCalendar.Parsha.NONE if the date is a weekday or if there is no parsha that week (for example Yom Tov that falls on a Shabbos).
The problematic code can be seen at line 1056 of the formatter.

I was wondering why the SunTimesCalculator() is the default calculator in AstronomicalCalculator.java lines 83-85 instead of the more precise NOAACalculator() ? The latter, for example, makes a difference between years, while the former just returns the same zmanim every year (counting the days from 1 January).

The current ZmanimCalendar#getChatzos() uses the midpoint between sunrise and sunset (see AstronomicalCalendar.java#getSunTransit()). As you say, this is following most opinions. On the other hand, I have found some poskim actually using the real transit time for their calculation and it would be very useful to have access to it.
Using the NOAACalculator#getSolarNoonUTC() an actual transit calculation is available, but given that it is a private method, it cannot be accessed externally.
I would suggest to:

1. change ZmanimCalendar#getChatzos() to there calculate use the sunrise and sunset instead of calling getSunTransit()
2. to create a getSunTransit() in each AstronomicalCalculator implementation
3. to redefine the AstronomicalCalendar.java#getSunTransit() to calculate using a call to the getSunTransit() in the underlying AstronomicalCalculator.
4. or as alternative to 2. and 3. provide a default in AstronomicalCalculator itself which can then be overridden in e.g. NOAACalculator

In Hebrew Yerushalmi names
Is \ Kilayim כלאיים
supposed to have 2 (י)s (Yuds)
I have seen it with one
if its a legitimate alternative spelling i guess leave it as is

In library and in site i get wrong Alos 16.1°

Calculations for the time of a given solar transition is largely based on coordinates for the given date at GMT which is further offset to a major degree by longitude. If the longitude is East of 0 (positive), the time will be advanced. If the longitude is West of 0 (negative), the time will be pushed back.

However, there is a unique case where the time actually advances where the longitude is West of 0 - and that is in locations with Time Zones that cross over the antimeridian. One example of this is Apia, Samoa (-13.8599098,-171.8031745) which has a West longitude but uses a timezone of +14:00. (There are several other examples, this is just the most extreme).

When the date is '2017-10-15' in Apia, there are other locations at roughly the same longitude (for example Pago Pago) that are observing a date of '2017-10-14'. Conversely, when Pago Pago is observing '2017-10-15', Apia is already observing '2017-10-16'.

Asking the calculator to give us the zmanim for 2017-10-15 in Apia will actually produce the zmanim that reflect where the sun would be in Apia when it is 10-15 in a place like Pago Pago. By this time, it is actually 10-16 in Apia. However, the logic coerces the date to 10-15 without regard for this discrepancy.

I believe the correct behavior in this scenario would be to ask the calculator to operate using 10-14. The UTC time returned will correctly adjust to 10-15 when the +14:00 offset is applied. The trick would be in recognizing this scenario.

• Zman.DATE_ORDER - Since Date is nullable, getZman() can return null.
• Zman.NAME_ORDER - Since String is nullable, getZmanLabel() can return null.

I want to see the zmanim of Hifa in israel but i can't make the right req, what is the correct url plz??

Why does rosh hashana(h) have two different spellings? (Seems reminiscent of #213) Same for Suk(k)ah, Kesub(v)os, Ta(')anis, Megil(l)ah, Kidushin, Horayos, Bava Kama, Makos, Nidah.

And while I am at it may I add that:

• Gitin
• Midos
• Bikurim
• Chalah
  should be spelled
• Gittin
• Middos
• Bikkurim
• Challah
  like you spelled Chullin, Shabbos, Megillah, Sukkah, Makkos, Kamma, Kiddushin, Kinnim, Niddah? Same grammar rule.
  And Kilayim should be spelled Kil'ayim like Ma'aseros, Pe'ah, etc.?

Although the user can change it, I think the defaults should make sense.
Maybe an official transliteration policy? (I personally have an extreme and clearly articulated opinion on transliteration, but I think it at least lays out the edge cases. Rules 10 and 13 there would solve the inconsistency between Tfila and Rosh Hashanah/Avodah Zarah)

How do i add a day to the calendar?

I'm still playing with this as i learn to use it (in vb, via ikvm). So, i may just be doing it wrong. Anyway, i want to list times, parasha, daf, and probably the date. Times uses ZmanimCalendar; parasha and daf use JewishCalendar; date uses JewishDate.

I set up a few variables to get the object i think i need:

Private ReadOnly Today As New JewishCalendar
Private ReadOnly Shabbos As New JewishCalendar
Private ReadOnly Yom As New JewishDate
Private ReadOnly Zmanim As New ZmanimCalendar(New util.GeoLocation(Name, Latitude, Longitude, java.util.TimeZone.getTimeZone(TimeZone)))

formatParsha() requires it to be Shabbos, so i used this successfully:

Dim Saturday As Date = Date.Today.AddDays(DayOfWeek.Saturday - DateAndTime.Today.DayOfWeek)
Shabbos.setGregorianDate(Saturday.Year, Saturday.Month - 1, Saturday.Day)
Debug.WriteLine(Formatter.formatParsha(Shabbos))

Daf needs no calculations, so:

Debug.WriteLine(Formatter.formatDafYomiBavli(Today.getDafYomiBavli))

The date is easy as well:

Debug.WriteLine(Formatter.format(Yom))

Okay, now it is a new day, and i want to show the date, time, and possibly new parasha. Do i have to reset each of the objects, or is there a way to advance the day by one easily.

Being a Jewish calendar I would expect it to begin at nightfall. However, from looking at the code it seems that it always uses the regular Calendar date, which begins at midnight. This can result in incorrect results.

Consider the following:

JewishCalendar jcal = new JewishCalendar();
if (jcal.isAssurBemelacha())
    System.out.print("Please don't use on Shabbat or Jewish Holidays");

This would consider even after nightfall on Saturday as if it is Shabbat (and therefore isAssurBemelacha() would evaluate to true), while it should not consider it to be Shabbat (and isAssurBemelacha() should evaluate to false).

Shouldn't this be >= instead of >? If 30 minutes is equal to the second zman, return 30 minutes (or the other zman, depending on how you look at it). Is this not semantically equivalent to Math.max()?

Same for this:

Hey,
I'm trying to create JAR file from this library to use the last version in my android app, but I get JAR file with errors, so I can't use it.
Maybe do you can please to add explaination how to use this code library in java/android project or how to create JAR file?

Thanks

Thanks.

Hi
I'm working on porting the zmanim library to VBA (and Visual Basic 6), It's mostly based on yparitcher's C port libzmanim (as I personally prefer procedural code...)

The repo is at:
https://github.com/diaphone1/vbzmanim
Two functional samples are included - A macro enabled Excel file and a VB6 sample
If you see it fit, please add to the ports list
Thanks

Why are negative elevations illegal in net.sourceforge.zmanim.util.GeoLocation ?
Should work for locations at Dead Sea (-400m).

If the unit tests pass, GitHub Actions can be set up to automatically run them on each push, PR, etc.

per https://github.com/KosherJava/zmanim/blob/master/src/net/sourceforge/zmanim/hebrewcalendar/JewishCalendar.java

The methods used to obtain the parsha were derived from the source code of HebCal by Danny Sadinoff and JCal for the Mac by Frank Yellin. Both based
their code on routines by Nachum Dershowitz and Edward M. Reingold. The class allows setting whether the parsha and
holiday scheme follows the Israel scheme or outside Israel scheme. The default is the outside Israel scheme.

I understand that KosherJava started out as GPL, but is now LGPL. Can you describe how that jibes with the GPL nature of the code used here?

What steps will reproduce the problem?
1. Build via ant. :)

What is the expected output? What do you see instead?

Right now, the build process uses ant, which means installation and use for and 
by maven projects is more difficult than it should be. Maven is idiomatic for 
Java, or nearly so.

What version of the product are you using? On what operating system?

1.3.0-beta.

Please provide any additional information below.

I have built a maven project from the current SVN repository source; if this 
would be an issue worth resolving, I'd be more than happy to contribute the 
patch.

Original issue reported on code.google.com by [email protected] on 7 Dec 2012 at 9:11

getParsha() defined here returns Parsha.NONE if the day is not Saturday. However, the parsha of the week is defined for any week by the parsha that is going to be read on that shabbos. So why don't we add logic to getParsha() to return the parsha that is due to be read on the upcoming Saturday

A lot, if not all, of the code in GeoLocationUtils is duplicated in GeoLocation. One or the other can be removed.

Also, a lot of the geodesic code looks like it's not used at all.

i don't understand this code, cause it looks like it accounts if it's weekdays and only if it's not, it would accont for it.
without this check i would check , i would get "מחר ר"ח " as the image displayed.
yomtov getmacharchodesh(hdate date) { if (date.wday) { return CHOL; } if (date.day == 30 || date.day == 29) { return MACHAR_CHODESH; } return CHOL; }