Introducing ZmanimMap.com

The Zmanim Map showing zmanim and the day and night shadow

The Zmanim Map was first published on KosherJava in 2007. Since that time it has gone through a number of iterations, improving with each release. The latest release, Zmanim Map 4.0, now has a home at ZmanimMap.com (the old map URLs continue to work).

This release is the most significant improvement to the map since its inception, with hundreds of changes. The map was rewritten from the ground up, and very little of the 3.5 release of November 2012 remains. A great deal of work went into keeping the map simple for someone who wants nothing more than today’s zmanim, while allowing anyone who wants more control to change almost every option. The defaults were chosen so that the settings never have to be opened. The following is a partial list of the new features.

The Map

  • The map was rebuilt from scratch, designed for a phone screen first rather than squeezed down from the desktop version. It opens much faster than the old map, and the buttons no longer jump around as the page finishes loading.
  • The map can be drawn with Google Maps or with OpenStreetMap tiles, selectable in the settings.
  • A new coffee brown, beige and cream theme was added, along with a dark mode that follows the system setting or can be set by hand.
  • The map is built as a progressive web app and can be installed on a phone’s home screen or on a desktop like an app. Once it has been loaded, it works with no connection at all, including the zmanim themselves.
  • On phones the zmanim open in a sheet that slides up from the bottom of the screen and can be dragged to the height you want, rather than in a small map bubble. On wide screens they can be docked as a panel alongside the map.
  • Clicking the marker shows the latitude, longitude, elevation and timezone of the point, and the elevation used for the zmanim calculations. The link button produces a URL for the current location, date and settings that can be bookmarked or emailed.

The Zmanim

  • The zmanim are listed in chronological order, with a countdown to the upcoming zman, which is highlighted.
  • The zmanim shown in the Zmanim tab are selected by the user. The full list of about 160 zmanim remains available in the More Zmanim tab.
  • Sha’os zmaniyos durations are listed for the various opinions.
  • Chametz zmanim (sof zman achilas and biur chametz) are shown only on Erev Pesach.
  • Polar zmanim were added for extreme latitudes where the sun does not cross the horizon on the given day, including the sunrise, sunset and plag hamincha of the Ben Ish Chai, and the start of the day and plag hamincha of the Teshuvos Vehanhagos.
  • Zmanim that have already passed are dimmed.
  • The following information is displayed above the zmanim as applicable. The day of the week, its Hebrew date, the parshah, Yom Tov, Rosh Chodesh, Chanukah and the day of the omer. In the zone where the authorities disagree about the date, the panel says so.
  • On a fast day the panel gives the start and end of the fast.
  • A solar elevation strip can be shown above the zmanim, off by default and a single setting away. It shows how far the sun is above or below the horizon at the selected location and time, with a gauge of the twilight bands that can be expanded. On a polar day it names the condition (midnight sun or polar night). For anyone well versed in zmanim, the elevation in degrees is often the quickest answer to what the sun is actually doing. At high latitudes it also explains why a zman may not occur at all, because the sun never reaches the depth below the horizon that the zman requires. A flight from Los Angeles to Tel Aviv is a good example: the great circle route runs far enough north that the sun may never drop to the depth of tzais hakochavim, leaving it unclear whether sefiras haomer can be counted that night.
  • The calculation algorithm is selectable. Meeus and SPA were added to the NOAA and USNO algorithms that the map already offered (both as part of the KosherJava 3.0 release). The three modern algorithms agree to within seconds of each other.
    • NOAA – the default. It has been part of the KosherJava library for many years, and is based on NOAA’s implementation of Jean Meeus’s low-accuracy algorithm.
    • Meeus – Jean Meeus’s high-accuracy algorithm. While its underlying solar-position accuracy is roughly an order of magnitude better than NOAA’s low-accuracy method, this translates to only a few seconds of improvement for typical sunrise and sunset calculations, and generally much less significance for practical zmanim.
    • SPA – the Solar Position Algorithm developed by the National Laboratory of the Rockies (formerly the National Renewable Energy Laboratory, NREL). It is another high-accuracy algorithm based on Meeus, with a published uncertainty of about 1 arc-second. In practice its results for sunrise and sunset are under 1 second from an exact ephemeris, essentially the same level as Meeus for zmanim.
    • USNO – based on the old U.S. Naval Observatory Astronomical Almanac algorithm. It is substantially less accurate than the other three and is no longer considered state of the art. It is retained for reference and for comparison with older implementations.

The Time Slider and Twilight Bands

The day and night shadow is no longer a fixed set of bands. The user selects which twilight bands are drawn, from the sunrise and sunset edge through the commonly used tzais, misheyakir and alos degrees, with each band drawn at exactly its angle. Enabling only the ones that you follow will show that opinion on the map and nothing else.

A time slider sits below the map. Dragging it moves the shadow across the earth for the selected date and location, so you can watch where the sun actually is at alos or tzais, instead of taking the number on trust. The track of the slider is painted with the day itself: night at the ends, daylight in the middle, twilight blended between them. Sunrise and sunset are marked on the track, along with a marker showing where the current time falls.

Finding a Location

  • The map can find your location automatically at load (once permission has been given), and a locate control on the map will find it again at any time.
  • The search box completes addresses as you type, with a plain search as a fallback.
  • Airport codes are recognized in the search box. Typing a 3-letter IATA or 4-letter ICAO code from the included database of over 4,000 airports with scheduled service will drop the pin at that airport.
  • The name of the selected location is looked up and shown on the map, together with its coordinates, elevation and timezone. Ocean points and other unnamed places just show the coordinates.
  • Locations can be saved and returned to from a list.
  • The browser’s Back and Forward buttons step through the locations the pin has visited, and each stop’s URL is a link that can be bookmarked or emailed. Links carry the location, zoom, map type, date, timezone, algorithm and the display options.
  • The date selector has previous and next day arrows and a Today button that also sets the map to move to the next day at midnight again.

Direction to Yerushalayim

The direction tab now has a compass. It normally points the way on its own, and on phones that support it the needle can track the direction you are facing, so you can turn until it points straight ahead. A toggle switches between the great circle and rhumb line bearings. The needle, pointer and readout are colored to match the lines on the map.

Calendars and Downloads

  • Weekly and monthly zmanim calendars can now be printed. They are generated in the browser, so they work offline, using the zmanim selected for the Zmanim tab. They include the Hebrew date, Yom Tov names, the parshah, Rosh Chodesh, the omer and candle lighting on Erev Shabbos and Yom Tov, including after nightfall where that applies, and print in the language of the page on either Letter or A4. A preview opens with navigation between weeks or months before printing or saving as a PDF.
  • The annual Excel calendar is still available, and is now offered explicitly in both its standard and full zmanim forms.

A Multilingual Map

For the first time the map is available in languages other than English. It is fully translated into English, Hebrew, French, Spanish, Russian and Ukrainian, including the About text and the explanations, with a right-to-left layout for Hebrew. Additional languages may be added in the future.

The language you choose changes the words. Your browser’s region decides the date and number formats, and whether distances are in miles or kilometers. An English-speaking user in London sees metric units; one in New Jersey does not. The Google Maps labels and the looked up place names follow the selected language as well.

Settings

The old map had no settings, and what you saw was what everyone saw. Version 4.0 has a settings screen, and almost everything on it is a choice that the map could not previously offer. Each setting has an information icon explaining what it does.

  • The zmanim that appear in the Zmanim tab, and whether times are shown to the second or rounded to the minute.
  • Light, dark or the system theme, and imperial or metric units.
  • The language.
  • Reset to default is a category picker rather than an all or nothing button, so the settings can be cleared without losing the saved locations, or the reverse.

Which lines and shading appear on the map is chosen here as well, along with the base map and how the zmanim are shown on a wide screen.

The settings are remembered on the device, and travel in the link, so that a link that is shared opens the way it was set up.

Backup, Restore and Sharing

  • Backup and Restore exports the saved locations and settings to a single file, and imports them back. Importing adds what is missing, so importing the same backup twice does nothing.
  • Sharing uses the phone’s share sheet where it is available, and links that are shared show a preview naming the location.
  • Printing produces a proper sheet with the location, the timezone and a map of the point.

Accessibility

The map can be used with a keyboard as well as with a mouse or touch, works with screen readers, and can be navigated with a keypad on feature phones. The buttons and controls were sized to be tapped reliably on a small screen.

Flight Mode

A flight mode that calculates zmanim along an airline route is in advanced beta testing, and is not yet open to the public. A separate article will cover it. Anyone interested in testing it is welcome to contact me.

Still in the Map

The map still does everything that it did before. The rhumb line and great circle bearings to Har Habayis, the halachic date lines with their graira areas, the date selection and the elevation lookup were all rebuilt on the new code, and can now be drawn on either base map.

The KosherJava Zmanim library that the map is built on remains open source under the LGPL 2.1. The map itself is not.

Your feedback is important. Please be in touch with any suggestions, issues or clarifications.

KosherJava Zmanim Library 3.0.0 Released


The KosherJava Zmanim API version 3.0.0 was released on Oct 21, 2026 י׳ חשון תשפ״ז in Maven and GitHub.

This is a major release, and unlike the releases that came before it, it will break existing code. The API has moved to java.time, a number of classes and methods were renamed, and the methods that had been deprecated over the years were removed. The zmanim themselves are almost all unchanged; what changed is what they are called and what type they return. Allow some time for the upgrade, and see the full list of changes since the 2.5.0 release in GitHub.

New in Version 3.0.0

Two New Calculators

  • The MeeusCalculator implements Jean Meeus’s high-accuracy algorithm. The existing NOAACalculator, which remains the default, is based on NOAA‘s implementation of his low-accuracy algorithm.
  • The SPACalculator implements the Solar Position Algorithm. Both new calculators are more accurate and slower than the NOAA calculator, though for practical zmanim the difference is a matter of seconds.
  • The USNO-based SunTimesCalculator is now deprecated. It is less accurate than the other three and is only being kept for reference and comparison with older implementations.

Breaking Changes

  • The minimum supported JRE is now Java 11, up from Java 8. Note that the JavaDocs only generate properly under Java 21. This affects generating the documentation, not the compiled code, which continues to target Java 11.
  • The API uses java.time throughout. All zmanim return Instants rather than Dates, sha’os zmaniyos return a Duration (and null rather than Long.MIN_VALUE when not applicable), Calendar and GregorianCalendar gave way to LocalDate and ZonedDateTime, TimeZone to ZoneId, and SimpleDateFormat to DateTimeFormatter. The now obsolete com.kosherjava.util.Time class was removed.
  • The confusingly named ComplexZmanimCalendar is now the ComprehensiveZmanimCalendar.
  • Generically named methods in the ZmanimCalendar were renamed to say which opinion they calculate. The zmanim did not change, only the names: getTzais() is now getTzaisGeonim8Point5Degrees(), getAlosHashachar() is getAlos16Point1Degrees(), getSofZmanShmaMGA() is getSofZmanShmaMGA72Minutes(), and getMinchaGedola(), getMinchaKetana() and getPlagHamincha() gained a GRA suffix. Minute-based zmanim now spell out Minutes, and getChatzos() is getChatzosHayom().
  • Parsha was renamed Parshah, in the formatters as well, and the misspelled isAssurBemlacha() and getBainHasmashos() methods were corrected.
  • Deprecated methods flagged for removal are gone, among them getSofZmanShmaKolEliyahu(), the fixed local chatzos based zmanim, and the JewishCalendar tefila methods that moved to TefilaRules. The redundant GeoLocationUtils class was removed in favor of GeoLocation.
  • A few zmanim that were a drop too early were corrected. getTzaisGeonim4Point37Degrees() is now getTzaisGeonim4Point42Degrees() and getTzaisGeonim4Point61Degrees() is getTzaisGeonim4Point66Degrees(). getTzaisGeonim5Point88Degrees() was removed.
  • The getSofZman*Chametz* methods return null when it is not Erev Pesach.
  • The source is now UTF-8, so the Hebrew in the documentation and code (particularly in HebrewDateFormatter) appears properly.

Chatzos

  • getChatzosHalayla() was added, calculated as astronomical midnight rather than as halfway between sunset and sunrise or twelve hours after chatzos hayom.
  • Two settings control how chatzos is used: useAstronomicalChatzos (on by default, retaining the backwards compatibility break introduced in 2.5.0) and useAstronomicalChatzosForOtherZmanim (off by default). getChatzosAsHalfDay() returns half-day chatzos regardless of the setting.
  • The generic getHalfDayBasedZman(startOfHalfDay, endOfHalfDay, hours) replaces getFixedLocalChatzosBasedZmanim() and allows other zmanim to be based on chatzos, and getPercentOfShaahZmanisFromDegrees(degrees, sunset) simplifies percentage-of-the-day calculations.

The Sun’s Position, and the Arctic

  • Solar azimuth and elevation were fixed in the NOAACalculator, and getSolarAzimuth(Instant, GeoLocation) and getSolarElevation(Instant, GeoLocation) were added to the AstronomicalCalculator, along with getTimeAtAzimuth(azimuth) in the AstronomicalCalendar.
  • The sun’s apparent angular semi-diameter for the day is now used by default rather than a fixed radius.
  • getPolarPlagHaminchaBenIshChai() and getPolarStartOfDayTeshuvosVehanhagos() were added for latitudes where the sun does not cross the horizon, together with getSunriseOrEasternmostSolarAzimuth() and getSunsetOrWesternmostSolarAzimuth().
  • The USNO noon calculation was corrected in locations where it was sometimes twelve hours off, and getInstantFromTime() was tweaked to address issues near the dateline.

The Calendar Classes

  • JewishCalendar gained getTekufa() and getTekufaAsInstant() for the tekufos, plus and minus methods for years, months and days matching LocalDate, and a public isJewishLeapYear(int). isHavdalahRecited() was renamed isTonightMutarBemelacha(), isYomTov() now returns true for 20 Nissan, and getDaysInJewishMonth() and getLastDayOfGregorianMonth() take their parameters in year, month order.
  • HebrewDateFormatter gained formatParsha(Parshah), and getHebrewMonthList() / setHebrewMonthList(String[]), which allow overriding the default month names such as Cheshvan to Marcheshvan.
  • TefilaRules gained isMizmorLesodaRecited(), and no longer has Tachanun recited on Erev Rosh Hashana.
  • ComprehensiveZmanimCalendar gained getMisheyakir12Point85Degrees(), getSofZmanAchilasChametzMGA72MinutesZmanis() and getSofZmanBiurChametzMGA72MinutesZmanis(), and a getMinchaGedolaGreaterThan30(Instant) that works with any mincha gedola calculation.

A number of other small changes, null-handling corrections and bug fixes are in the full list of changes. I would like to thank Moshe Dicker, Elyahu Jacobi and Maor Na’im of RoyZmanim, and many others who helped with code that went into this release. I would also like to thank Eli Julian for his continued release support skills.

User Interface Update to El Al’s Zmanim App

El Al’s Latest Zmanim App. Note the latitude and longitude on the display as well as the version number.
While there have been many technical updates to El Al’s in-flight zmanim app since it rolled out, none included changes to the visual user interface. In February, El Al rolled out a long awaited update by FlightPath3D to the user interface based on feedback received since the initial system was rolled out. The new UI has many enhancements including:

  • Displaying the latitude and longitude on the main screen to allow people to more easily validate the accuracy of zmanim calculations and simplify bug reporting. This feature involved a security review by El Al. To enhance reporting even further, the app version is displayed on the main screen. I am not aware of any software that shows the version on the main app screen, but we are doing what we can to help resolve any potential issues, and knowing the version number can help. Since feedback is often in the form of a picture of the screen, displaying the aircraft location and version number on the screen simplifies debugging issues.
  • A UI toggle to show a more extensive list of zmanim (not just a few past and upcoming ones).
  • Avoid showing the zmanim screen before takeoff (projections on the ground are too inaccurate, since the system has no idea when it will take off). Even showing zmanim for specific cities prior to takeoff was shelved in a UX review since it would likely confuse users who would think that it reflected the flight zmanim. The icon for displaying zmanim shows up as soon as the flight is underway.
  • Minor FAQ changes, including the addition of QR codes to simplify contacting us to report issues. Thank you YCS for the suggestion.
  • The Halachic Datelines (the Chazon Ish and Rav Yechiel Michel Tucazinsky) were added to the flight map. Note that graira / גרירה is used in the Chazon Ish (west) date line, but not Rav Tucazinsky’s (east) date line, since he was seemingly מסופק / unsure about concept. This change was a mapping update, and not a zmanim app update.

Time Zone Database – A Critical But Overlooked Zmanim Component

An important aspect of calculating accurate zmanim, is ensuring that the timezone information on the computer generating the zmanim is kept up to date. The volunteer maintained IANA time zone database (also known as the tz, zoneinfo or Olson database) is used globally by computers to store time zone information. Failure to keep up to date with the latest database will result in potentially generating zmanim that can be off by an hour or more in parts of the world. This time zone database is updated multiple times a year as locations around the world change their time zone information. Often changes are to the start and end of DST in various zones, but it sometimes includes year-round changes and newly introduced time zones that have rules differing from the geographic area around them. There is a general lack of awareness by zmanim software developers and system maintainers hosting zmanim apps, of the criticality of keeping this data up to date. A lack of keeping it up to date can result in the possibility of significant issues in zmanim calculations. Subscribing to the tz announcements mailing list will keep you up to date on the latest zone changes.

Timelines for Time Zone Data Updates

There are times when updates to the database are not released until after the changes take effect, and there are cases where the announcements are made very shortly before they take effect. An example of this was Lebanon’s 2023 change and reversal. On Mar 23, 2023 Lebanon announced that the DST that had been scheduled to start 2 days later on Mar 25 was being postponed to Apr 20. The IANA time zone database 2023b was released a day later on Mar 24 (2 days after the 2023a release). On Mar 27 they announced that they were moving to DST on Mar 29. On Mar 27, 2023c was released that restored an identical version to what had been released in 2023a.
Here is a timeline from the 2024a update for Kazakhstan (that has a small Jewish community impacted by the change). The change unified time zones for the entire country (that stretches 3,000 km /1,900 mi from east to west and geographically spans 4 time zones) from two (UTC+6 and UTC+5) to one UTC+5 zone. The timeline shows that despite being on top of things, you can’t always ensure that you are up to date.

  • Oct 19, 2023 – Discussions started about a proposed change to unify Kazakhstan on a single time zone. On Nov 12, 2023 – A draft decree about the change was published.
  • Dec 7, 2023 – The Kazakh Ministry of Trade and Integration announced the proposal to formalize the changes.
  • Jan 19, 2024 – 2024 decree no. 20 was formalized by the Kazakh government and brought to the attention of the IANA Time Zone Database maintainers.
  • Feb 1, 2024 – The time zone data change was released as 2024a.
  • Feb 2, 2024 – PECL timezonedb package was released.
  • Feb 4, 2024 – Moment.js‘s Moment Timezone releases v0.5.45 with the change.
  • Feb 14, 2024 – Android Mainline PR is merged. It would be available to most Android 10 devices within 24 hours. Older Android versions will have to wait for the next release.
  • Mar 1, 2024 – At the stroke of midnight, the clocks in part of Kazakhstan rolled back to Feb 29 at 11pm, resulting in a 25 hour leap year leap day.
  • Mar 6, 2024 – Node.js code was initially updated on the main branch on Feb 15 and an issue was opened on March 1 to have a release with the updated zone information. The non-LTS version 21.7.0 with the change was released om March 6. LTS versions 20.0.12.0 and 18.20.0 with the changed were released on March 26, 26 days after it took effect.
  • Mar 26, 2024 – Windows made the first update available via the March 2024 non-security preview update (that most do not install), 26 days after the change took effect.
  • Apr 9, 2024 – General availability of the Windows patch was released, 40 days after it took effect.

Updating Operating Systems and Various Languages

Below are the basics for keeping your system’s time zone database up to date. Note that there are times when the announcements of changes do not give much warning, and it is not always possible to keep perfectly up to date on some platforms. If you have information on languages and systems not covered here, please post information in the comments section.

  • Windows – Keep your Windows Updates up to date with optional updates. Systems set for security updates only, will never receive this update. See the information above on the windows portion of the timeline section.
  • Linux – Patches are usually available immediately after the release by the IANA team. Here is some info, but be sure to read the manuals before trying things. Ubuntu you would run something like sudo apt update && sudo apt upgrade -y tzdata. For Redhat it would involve something like sudo dnf update && dnf upgrade -y tzdata.
  • Android devices receive timely time zone updates for the devices current location, that will often not address issues in updating zone information for other locations. When generating zmanim for another location, care must be taken to ensure that the underlying zone database is up to date. Note that as of Android 10 (released in Sep, 2019 and currently only on about 20% of devices), the TZDB module was enhanced to update via the Mainline modules system that speeds up deployment of the updates. The Android tzdata process was enhanced late in 2023 to separate this to a standalone process that can be quickly updated multiple times a year without having to wait for other Mainline updates. Developers who want to package their own database to support older Android devices can package the Joda-Time for Android with their app, but they would have to ensure that they update their app every time a new zone database is released.
  • Java provides a TZUpdater tool (download) that can can be used to update the time zone database in Java. Having the latest Java release is not reliable enough, since there are time zone changes more often than the twice yearly release (though minor versions are updated more often).
  • JavaScript / TypeScript that use Moment would have to update their package.json and run npm install to receive updates. Luxon seems to use the operating system’s tzinfo. See info for Linux and Windows above. For other packages or libraries, research is needed.
  • PHP out of the box only updates the zone data on new releases, They maintain the timezonedb PECL package to deal with cases (like ours) where up to date zone data is needed, but it requires regular updates.
  • Python uses the operating system’s tzinfo. See info for Linux and Windows above. Alternatively, use pytz.
  • Ruby uses the operating system’s tzinfo. See info for Linux and Windows above.
  • Go uses the operating system’s tzinfo. A standalone copy can optionally be embedded in the Go executable.
  • iOS – I was unable to find any reliable information on the subject. Apple support declined to provide any information on the subject besides confirming that they push time zone updates in a timely manner.

For many systems, cron or other jobs are needed to keep the database updated on a regular schedule. For many, a restart of the system may be required.

Warning: Inexpensive shared hosting poses significant challenges to keeping your system zone database current. There are many aspects that you have no control over, and keeping the time zone database up to date is often not high on the agenda of risk-averse shared hosts.

Additional Complexities with Mobile Devices

There is an additional set of complexities for time zones for mobile devices. While this affects Macs and possibly Windows, very few if any are using native zmanim apps on those platforms.

  • One of the more common complaints about incorrect zmanim end up being caused by the device being set to the incorrect time zone. Most devices change their zone automatically, but some users manually change things and when they travel to a different zone without changing the zone, it results in incorrect zmanim. Mobile developers should explore detecting that the time zone on the device is different than the expected time zone, and alert the user to check the devices time zone setting, while ensuring that it does not have issues when there is no cellular signal (such as when flying).
  • Users in Israel may find themselves in areas where the phone sets the zone to Asia/Hebron or Asia/Gaza. Those areas have different DST rules than Israel, and will cause issues when the DST rules differ. A way to handle this situation in an app is to ensure that the app detects the setting of these two zones and use Asia/Jerusalem. I am unsure if Israeli cell providers return the expected zone setting in the West Bank (or Gaza).

Here is sample java.time.ZoneId code to address the second issue.

ZoneId zi = ZoneId.of("Asia/Hebron");
if((zi.getId().equals("Asia/Gaza") || zi.getId().equals("Asia/Hebron"))){
    zi = ZoneId.of("Asia/Jerusalem");
}

Historical List of Time Zone Changes

To give an idea of the scope of time zone changes (that some assume are rare or trivial), here is a list of changes to the database. The year 2009 sticks out with 21 published changes to the database, but as you can see, there are many years numerous changes published. This list excludes technical, historical (where there are corrections to the history of time zone changes years after the fact) and some irrelevant changes. There are many examples where a location made changes more than once a year, and those are not broken out. You can see some patterns here of countries that change very often. Ramadan is a cause of many changes in Muslim countries.

YearUpdatesUpdated areas and Zones
20266Correct Moldova’s DST time-of-day changes, remove Europe/Chisinau because it matches Europe/Athens, British Columbia moved to permanent -07, Alberta moved to permanent -06, Morocco moved to permanent +00, Northwest Territories moved to permanent -06, and Manitoba moved to permanent -05, Cuba moved to -04 year round
20253Paraguay to use DST (-3) all year, New zone for Aysén Region in Chile (America/Coyhaique), historical data for Baja California.
20242Kazakhstan (unified Asia/Almaty and Asia/Qostanay). Improve historical data for Mexico, Mongolia, and Portugal.
20234Egypt, Palestine, Morocco, much of Greenland and Lebanon.
20227Chile, Palestine, Iran, Jordan, Syria, Mexico (except near the US border), Chihuahua, Fiji, northern edge of Chihuahua, much of Greenland).
20215South Sudan, Jordan, Samoa, Fiji, Palestine
20206Morocco, Canada’s Yukon, Casey (Antarctica), Fiji, Palestine, Volgograd.
20193Metlakatla, Palestine, Brazil, Fiji, Norfolk Island.
20188São Tomé and Príncipe, Brazil, Palestine, North Korea, Volgograd, Fiji, most of Chile, Morocco, Qyzylorda (Kazakhstan) and Metlakatla, Alaska. New zone Asia/Qostanay.
20173Mongolia, Chile, Haiti, Northern Cyprus, Fiji, Namibia, Sudan, Tonga, Turks & Caicos.
201610America/Cayman, Asia/Chita, Palestine, Asia/Tehran, America/Metlakatla, Asia/Sakhalin, Azerbaijan, Chile, America/Caracas, Asia/Magadan, Africa/Cairo, Asia/Novosibirsk, Turkey, Pacific/Tongatapu, Tonga and Antarctica/Casey. New zones Europe/Astrakhan and Europe/Ulyanovsk, Asia/Barnaul, Asia/Tomsk, Europe/Kirov, Asia/Famagusta, Europe/Saratov.
20157America/Cancun, Chile, Mongolia, Palestine, Egypt, Morocco, North Korea, Moldova Turkey, Norfolk, Fiji’s, Fort Nelson (BC, Canada).
201410Turkey, Fiji, Crimea, Egypt, Morocco, Russia (Magadan Oblast, Zabaykalsky Krai, Chukotka Autonomous Okrug, Kamchatka Krai, Kemerovo Oblast, Samara Oblast), Udmurt Republic, Turks & Caicos, Fiji, Quintana Roo (Mexico), Chile. New zones Asia/Chita, Asia/Srednekolymsk and Pacific/Bougainville
20139Chile, Haiti, Paraguay, Morocco, Palestine, Fiji, Tocantins, Israel, Jordan, Libya, Western Sahara, Acre, western Amazonas, Cuba. New Zones Asia/Khandyga, Asia/Ust-Nera, Europe/Busingen
201210Armenia, Tokelau, Chile, Falkland Islands, Cuba, Morocco, Haiti, Fiji, Samoa, Palestine, Bahia, Tocantins, Israel, Jordan, Libya. New zone America/Creston
201114America/North_Dakota/Beulah (Mercer County, North Dakota, Chile, Annette Island (Alaska), Samoa, Cuba, Turkey, Morocco, Palestine, Falkland Islands, Egypt, Russia, Newfoundland, Belarus, Ukraine, Tiraspol (Moldovia), Bahia (Brazil) and Fiji. New Africa/Juba (South Sudan) zones.
201015Mexico, Paraguay, Bangladesh, Samoa, Fiji, Chile, Dhaka, Australian (Antarctic), Kamchaatka, Anadyr, Samara, Tunisia, Pakistan, Morocco and Egypt. New “Bahia_Banderas” time zone added.
200921Cuba, Morocco, Tunisia, Argentina and Syria, Palestine, Jordan, Pakistan, Egypt, Bangladesh, Dhaka, Mauritius, Samoa, Fiji and Resolute
20089Chile, Cuba, Argentina, Morocco, Pakistan, Choibalsan (Mongolia), Brazil, Iraq (abandons DST). Mauritius’s 2008 DST experiment, and some localized Brazilian time zone realignments.
200711Asmara, Easter Island, Syria, Honduras, New Zealand, Australia (for 2008), America/Indiana, Brazil, Egypt, Iran, Venezuela, Cuba and Argentina.
200616America/Indiana and America/New Brunswick (Canada), Haiti, Sri Lanka, Egypt, Syria, Uruguay, Honduras, Bermuda, Moncton, Blanc-Sablon and Western Australia.
200514 Uruguay, Kyrgyzstan …

KosherJava Zmanim API 2.5.0 Released


The KosherJava Zmanim API version 2.5.0 was released on June 9, 2023 י״ג סיון תשפ״ג in Maven and GitHub.

New in Version 2.5.0

See the full list of changes between v2.4.0 and v2.5.0 in GitHub. I would like to thank Eli Julian for his continued release support skills.