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-announce 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 decree formalizing the changes.
  • Jan 19, 2024 – The changes were brought to the attention of the IANA Time Zone Database maintainers. It is not unusual for a delay like this in notifying the maintainers of a change.
  • 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 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.
  • Mar 26, 2024 – Node.js LTS versions 20.0.12.0 and 18.20.0 with the changed were released, 26 days after it took effect. The 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.x with the change was not yet released as of when this article was published.
  • 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.

Year Updates Updated areas and Zones
2024 1 Kazakhstan (unified Asia/Almaty and Asia/Qostanay).
2023 4 Egypt, Palestine, Morocco, much of Greenland and Lebanon.
2022 7 Chile, Palestine, Iran, Jordan, Syria, Mexico (except near the US border), Chihuahua, Fiji, northern edge of Chihuahua, much of Greenland).
2021 5 South Sudan, Jordan, Samoa, Fiji, Palestine
2020 6 Morocco, Canada’s Yukon, Casey (Antarctica), Fiji, Palestine, Volgograd.
2019 3 Metlakatla, Palestine, Brazil, Fiji, Norfolk Island.
2018 8 São Tomé and Príncipe, Brazil, Palestine, North Korea, Volgograd, Fiji, most of Chile, Morocco, Qyzylorda (Kazakhstan) and Metlakatla, Alaska. New zone Asia/Qostanay.
2017 3 Mongolia, Chile, Haiti, Northern Cyprus, Fiji, Namibia, Sudan, Tonga, Turks & Caicos.
2016 10 America/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.
2015 7 America/Cancun, Chile, Mongolia, Palestine, Egypt, Morocco, North Korea, Moldova Turkey, Norfolk, Fiji’s, Fort Nelson (BC, Canada).
2014 10 Turkey, 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
2013 9 Chile, Haiti, Paraguay, Morocco, Palestine, Fiji, Tocantins, Israel, Jordan, Libya, Western Sahara, Acre, western Amazonas, Cuba. New Zones Asia/Khandyga, Asia/Ust-Nera, Europe/Busingen
2012 10 Armenia, Tokelau, Chile, Falkland Islands, Cuba, Morocco, Haiti, Fiji, Samoa, Palestine, Bahia, Tocantins, Israel, Jordan, Libya. New zone America/Creston
2011 14 America/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.
2010 15 Mexico, Paraguay, Bangladesh, Samoa, Fiji, Chile, Dhaka, Australian (Antarctic), Kamchaatka, Anadyr, Samara, Tunisia, Pakistan, Morocco and Egypt. New “Bahia_Banderas” time zone added.
2009 21 Cuba, Morocco, Tunisia, Argentina and Syria, Palestine, Jordan, Pakistan, Egypt, Bangladesh, Dhaka, Mauritius, Samoa, Fiji and Resolute
2008 9 Chile, Cuba, Argentina, Morocco, Pakistan, Choibalsan (Mongolia), Brazil, Iraq (abandons DST). Mauritius’s 2008 DST experiment, and some localized Brazilian time zone realignments.
2007 11 Asmara, Easter Island, Syria, Honduras, New Zealand, Australia (for 2008), America/Indiana, Brazil, Egypt, Iran, Venezuela, Cuba and Argentina.
2006 16 America/Indiana and America/New Brunswick (Canada), Haiti, Sri Lanka, Egypt, Syria, Uruguay, Honduras, Bermuda, Moncton, Blanc-Sablon and Western Australia.
2005 14 Uruguay, Kyrgyzstan …

Zmanim Map 3.5 adds Date and Algorithm Selection

Vintage Map with CompassThe Zmanim Map was recently updated to version 3.5. This new release adds a number of new features (listed below), and some technical changes over the previous Zmanim Map 3.0 release. With this release, the main focus of the map has shifted to the zmanim tabs. The direction to Yerushalayim tab with davening directions using both the rhumb line and great circle route to Yerushalayim is still present, but is no longer the default tab.
Zmanim Map v3.5

  • The date can now be selected by the user. In previous versions the date was always the current date on the user’s computer (though the map always supported passing the date on the URL using the undocumented date=1969-02-08 parameter). The current date is still the default, but the user can now change the date.
  • The calculation algorithm is now selectable. The Zmanim API supports both the USNO and NOAA algorithms. The map has always used the USNO algorithm, and this remains the default, but users can now use the NOAA algorithm.
  • The Zmanim tab is now the default tab. This reflects user feedback indicating that most people use the map for zmanim.
  • An About tab now provides a mini user guide and general information about the map.
  • The timezone look-up now uses the Google Time Zone API. Previously the map had been using the Geo Names web service. Since the elevation service also uses Google, the change to a single stable source will hopefully result in fewer outages.
  • The currently selected tab persists across location changes, so if you were viewing zmanim for a location, and changed the location to see how the zmanim were affected, you will no longer have to change tabs after each move.
  • Candle Lighting was added for Fridays. Erev Yom Tov will not show candle lighting at this point.
  • Performance improvements, minor enhancements, bug fixes and refactoring

FAQ: Outputting Zmanim for A Different Time Zone With the Zmanim API

KosherJava Zmanim API FAQ

Question:

Why does the output of zmanim for a different time zone appear incorrect?

Answer:

One of the common issues encountered by developers using the API is that zmanim generated for a different time zone than the user’s time zone may return output that appears incorrect. For example a user in Lakewood, NJ trying to calculate sunrise for Yerushalayim may attempt to use the following code:

String locationName = "Jerusalem";
double latitude = 31.778; // Har habayis
double longitude = 35.2354;// Har Habayis
double elevation = 0;
TimeZone timeZone = TimeZone.getTimeZone("Asia/Jerusalem");
GeoLocation location = new GeoLocation(locationName, latitude, longitude, elevation, timeZone);
ZmanimCalendar zc = new ZmanimCalendar(location);
zc.getCalendar().set(2011, Calendar.FEBRUARY, 8);
System.out.println("Sunrise: " + zc.getSunrise());
System.out.println("Sunset: " + zc.getSunset());

While you would expect a sunrise of 6:27:41 AM and sunset of 5:19:19 PM, running this code on a computer anywhere in the Eastern Standard time zone would generate the following time that appears to be 7 hours early:

Sunrise: Mon Feb 07 23:27:41 EST 2011
Sunset: Tue Feb 08 10:19:19 EST 2011

The issue is simple, and the sunrise and sunset returned above are actually accurate. Zmanim are returned by the Zmanim API as a Java Date object that represents a moment in time (stored internally by Java as Unix Time – the number of milliseconds since the January 1, 1970 GMT). Sunrise in Yerushalayim on February 8th actually happens at 11:27:41 PM on February 7th EST. Java is simply outputting the Date as a String formatted to the users default time zone (EST in this example). The user probably intends to output the time in IST – Israel Standard Time (“Asia/Jerusalem” in the Olson database). To do this you have to output the zmanim using a formatter set to use the “Asia/Jerusalem” time zone.

DateFormat zmanimFormat = new SimpleDateFormat("EEE MMM dd HH:mm:ss z yyyy");
zmanimFormat.setTimeZone(location.getTimeZone());

System.out.println("sunrise: " + zmanimFormat.format(zc.getSunrise()));
System.out.println("sunset:" + zmanimFormat.format(zc.getSunset()));

will output the expected

sunrise: Tue Feb 08 06:27:41 IST 2011
sunset:Tue Feb 08 17:19:19 IST 2011

Below is the full code example.

import com.kosherjava.zmanim.*;
import com.kosherjava.zmanim.util.*;
import java.util.TimeZone;
public class FormatZmanim{
	public static void main(String [] args) {
		String locationName = "Jerusalem";
		double latitude = 31.778; //latitude of Har habayis
		double longitude = 35.2354; //longitude of Har Habayis
		double elevation = 0; //optional elevation
		//use a Valid Olson Database timezone listed in java.util.TimeZone.getAvailableIDs()
		TimeZone timeZone = TimeZone.getTimeZone("Asia/Jerusalem");
		//create the location object
		GeoLocation location = new GeoLocation(locationName, latitude, longitude, elevation, timeZone);
		ZmanimCalendar zc = new ZmanimCalendar(location); //create the ZmanimCalendar
		zc.getCalendar().set(2011, Calendar.FEBRUARY, 8); //set the date
		DateFormat zmanimFormat = new SimpleDateFormat("EEE MMM dd HH:mm:ss z yyyy"); //Create the formatter
		zmanimFormat.setTimeZone(location.getTimeZone()); //set the formatter's time zone
		System.out.println("sunrise: " + zmanimFormat.format(zc.getSunrise()));
		System.out.println("sunset:" + zmanimFormat.format(zc.getSunset()));
	}
}

Bearing to Yerushalayim and Zmanim Map 3.0

Vintage Map with CompassThe Bearing to Yerushalayim and Zmanim Map was recently updated to version 3.0. This new release adds a number of new features to the Zmanim Map version 2.0 update released in March 2010. The main change was updating the Google Map API version from the deprecated v2 to v3. This change increases performance and adds much better support for mobile browsers. The upgrade also means that a Google Maps API key is no longer required. This makes it easy to drop it into any site without any configuration (contact me for details). Zmanim tab v3The technical notes on the original Technical Information about the Bearing to Yerushalayim Map post are still relevant, with very little having changed since the initial implementation.

The following is a partial list of the new features:

  • A number of additional zmanim in the More Zmanim tab, including tchilas and sof zman kiddush levana (if they occur on that day)
  • A link to download a 12 month Zmanim calendar directly from the map (using the same spreadsheet used in the Zmanim Calendar Generator). Clicking on the link from the Zmanim tab will generate a calendar with most typically used zmanim, while clicking on the link in the More Zmanim tab will download the full set of zmanim. These are available as the Calendar Type option in the Zmanim Calendar Generator
  • Increased use of jQuery and jQuery UI for formatting the zmanim tables to better match the site look & feel
  • Refactoring to make the code more robust and slightly more maintainable
  • Timezones for all of Israel now display the timezone of Asia/Jerusalem as opposed to the Asia/Gaza returned for parts of Israel by the GeoNames TimeZone web service

From a technical perspective there were a number of changes required due to updating the Google Maps API from v2 to v3. These include:

  • v3 no longer supports tabbed info windows, so the tabs are now implemented using jQuery UI
  • Renaming of a number of classes and functions such as GLatLng to LatLng
  • A number of functions that were part of API v2 were removed in v3. One example is the removal of radians in the LatLng that had been available and was replaced by the google.maps.LatLng class. These missing functions required for the direction to Yerushalayim calculations are now supported in the Zmanim Map using prototypes

Bearing to Yerushalayim and Zmanim Map 2.0

Vintage Map with CompassThe availability of the Bearing to Yerushalayim and Zmanim Map was originally announced on December 30, 2007. At the time there were a number of bugs related to the Google Map API. These bugs were reported to Google and eventually fixed. Since that time, the only change was a minor JavaScript fix for IE. The Bearing to Yerushalayim worked, but the zmanim tabs had a major issue because the timezone calculated was done based on the user’s current browser timezone. This made it tricky to check zmanim in a different location or timezone than the user’s current timezone.Zmanim tab using timezonesI recently updated the map to look-up the actual timezone of the latitude and longitude selected by the user. This was implemented by doing a look-up at the geonames.org timezone web-service. The timezone is passed to the Zmanim API and used to generate the XML output of a list of daily zmanim that is displayed in the map. Since the Olson timezone database changes a few times a year, there will almost certainly be cases where the proper timezone can’t be determined. Some of these are changes of timezone names, such as the change from Asia/Calcutta to Asia/Kolkata (my host will not run the TZ Updater tool). In these cases, a simple mapping between the old and new was added to the map. In cases where the timezone can’t be determined the timezone will default to GMT. Ocean locations within 10 km of land will use the closest landmass, but anywhere beyond 10 km will default to GMT. One issue with using the geonames.org webservice, is that when it is down, the map will timeout. I experimented with various ways of dealing with this, but unless my host updates the Java version from 1.4, they are too complex to use at this time.

See the Technical Information about the Bearing to Yerushalayim Map post for technical details about the original implementation.