Time zone

History

The apparent position of the Sun in the sky, and thus solar time, varies by location due to the spherical shape of the Earth. This variation corresponds to four minutes for every degree of longitude; for example, when it is solar noon in London, it is about 10 minutes before solar noon in Bristol, which is about 2.5 degrees to the west. Local solar time has been associated with civil timekeeping since the development of sundials; for example, c.1500 BC, an ancient Egyptian sundial was used to measure laborers' work hours. In the 2nd century BC, Hipparchus developed a method to measure longitudinal distances by comparing local solar times when a lunar eclipse was simultaneously observed at two locations. The work of Hipparchus is lost, but is known from citations in Strabo's Geographica, c. 7 AD.

The Royal Observatory, Greenwich, founded in 1675, established Greenwich Mean Time (GMT), the mean solar time at that location, as an aid to mariners to determine longitude at sea, providing a standard reference time while each location in England kept a different time.

Railway time

In the 19th century, as transportation and telecommunications improved, it became increasingly inconvenient for each location to observe its own solar time. In November 1840, the British Great Western Railway started using GMT kept by portable chronometers. This practice was soon adopted by other British railway companies and became known as railway time.

Around August 23, 1852, time signals were first transmitted by telegraph from the Royal Observatory. By 1855, 98% of Great Britain's public clocks were using GMT, but it was not made the island's legal time until August 2, 1880. Some British clocks from this period have two minute hands, one for the local time and one for GMT.

On November 2, 1868, the British Colony of New Zealand officially adopted a standard time to be observed throughout the colony. It was based on longitude 172°30′ east of Greenwich, or 11 hours 30 minutes ahead of GMT. This standard was known as New Zealand Mean Time.

Timekeeping on North American railroads in the 19th century was complex. Each railroad used its own standard time, usually based on the local time of its headquarters or most important terminus, and the railroad's train schedules were published using its own time. Some junctions served by several railroads had a clock for each railroad, each showing a different time. Because of this, a number of accidents occurred when trains from different companies using the same tracks mistimed their passings.

Around 1863, Charles F. Dowd proposed a system of hourly standard time zones for North American railroads, although he published nothing on the matter at that time and did not consult railroad officials until 1869. In 1870, he proposed four ideal time zones having north–south borders, the first centered on Washington, D.C.. By 1872, the first was centered on the meridian 75° west of Greenwich, with natural borders such as sections of the Appalachian Mountains. Dowd's system was never accepted by North American railroads. Cleveland Abbe, chief meteorologist at the United States Weather Bureau, divided the United States into four standard time zones for consistency among the weather stations. In 1879, he published a paper titled Report on Standard Time. In 1883, he convinced North American railroad companies to adopt his time-zone system. In 1884, Britain, which had already adopted its own standard time system for England, Scotland, and Wales, helped gather international consent for global time. In time, the American government, influenced in part by Abbe's 1879 paper, adopted the time-zone system. It was a version proposed by William F. Allen, the editor of the Traveler's Official Railway Guide. The borders of its time zones ran through railroad stations, often in major cities. For example, the border between its Eastern and Central time zones ran through Detroit, Buffalo, Pittsburgh, Atlanta, and Charleston. It was inaugurated on Sunday, November 18, 1883, also called "The Day of Two Noons", when each railroad station clock was reset as standard-time noon was reached within each time zone.

The North American zones were named Intercolonial, Eastern, Central, Mountain, and Pacific. Within a year 85% of cities with populations over 10,000 (about 200 cities) were using standard time. A notable exception was Detroit (located about halfway between the meridians of Eastern and Central time), which kept local time until 1900, then tried Central Standard Time, local mean time, and Eastern Standard Time (EST) before a May 1915 ordinance settled on EST and was ratified by popular vote in August 1916. The confusion of times came to an end when standard time zones were formally adopted by the U.S. Congress in the Standard Time Act of March 19, 1918.

Worldwide time zones

Italian mathematician Quirico Filopanti introduced the idea of a worldwide system of time zones in his book Miranda!, published in 1858. He proposed 24 hourly time zones, which he called "longitudinal days", the first centred on the meridian of Rome. He also proposed a universal time to be used in astronomy and telegraphy. However, his book attracted no attention until long after his death.

Scottish-born Canadian Sir Sandford Fleming proposed a worldwide system of time zones in 1876 - see Sandford Fleming § Inventor of worldwide standard time. The proposal divided the world into twenty-four time zones labeled A-Y (skipping J), each one covering 15 degrees of longitude. All clocks within each zone would be set to the same time as the others, but differed by one hour from those in the neighboring zones. He advocated his system at several international conferences, including the International Meridian Conference, where it received some consideration. The system has not been directly adopted, but some maps divide the world into 24 time zones and assign letters to them, similarly to Fleming's system.

By about 1900, almost all inhabited places on Earth had adopted a standard time zone, but only some of them used an hourly offset from GMT. Many applied the time at a local astronomical observatory to an entire country, without any reference to GMT. It took many decades before all time zones were based on some standard offset from GMT or Coordinated Universal Time (UTC). By 1929, the majority of countries had adopted hourly time zones, though some countries such as Iran, India, Myanmar, and parts of Australia had time zones with a 30-minute offset. Nepal was the last country to adopt a standard offset, shifting slightly to UTC+05:45 in 1986.

All nations currently use standard time zones for secular purposes, but not all of them apply the concept as originally conceived. Several countries and subdivisions use half-hour or quarter-hour deviations from standard time. Some countries, such as China and India, use a single time zone even though the extent of their territory far exceeds the ideal 15° of longitude for one hour; other countries, such as Spain and Argentina, use standard hour-based offsets, but not necessarily those that would be determined by their geographical location. The consequences, in some areas, can affect the lives of local citizens, and in extreme cases contribute to larger political issues, such as in the western reaches of China. In Russia, which has 11 time zones, two time zones were removed in 2010 (one year before the daylight saving time would be observed all year round on March 27 of the following year) and reinstated in 2014 (when the country transferred from daylight saving time or summer time back to standard time or winter time permanently).

Notation

ISO 8601

ISO 8601 is a standard established by the International Organization for Standardization defining methods of representing dates and times in textual form, including specifications for representing time zones.

If a time is in UTC, a "Z" is added directly after the time without a separating space. "Z" is the zone designator for the zero UTC offset. "09:30 UTC" is therefore represented as "09:30Z" or "0930Z". Likewise, "14:45:15 UTC" is written as "14:45:15Z" or "144515Z". UTC time is also known as "Zulu" time, since "Zulu" is a phonetic alphabet code word for the letter "Z".

Offsets from UTC are written in the format ±hh:mm, ±hhmm, or ±hh (either hours ahead or behind UTC). For example, if the time being described is one hour ahead of UTC (such as the time in Germany during the winter), the zone designator would be "+01:00", "+0100", or simply "+01". This numeric representation of time zones is appended to local times in the same way that alphabetic time zone abbreviations (or "Z", as above) are appended. The offset from UTC changes with daylight saving time, e.g. a time offset in Chicago, which is in the North American Central Time Zone, is "−06:00" for the winter (Central Standard Time) and "−05:00" for the summer (Central Daylight Time).

Abbreviations

Time zones are often represented by alphabetic abbreviations such as "EST", "WST", and "CST", though these are not part of the international time and date standard ISO 8601. Such designations can be ambiguous; for example, "CST" can mean (North American) Central Standard Time (UTC−06:00), Cuba Standard Time (UTC−05:00), or China Standard Time (UTC+08:00), and is also a widely used variant of ACST (Australian Central Standard Time, UTC+09:30).

Conversions

Conversion between time zones obeys the relationship

"time in zone A" − "UTC offset for zone A" = "time in zone B" − "UTC offset for zone B",

in which each side of the equation is equivalent to UTC.

The conversion equation can be rearranged to

"time in zone B" = "time in zone A" − "UTC offset for zone A" + "UTC offset for zone B".

For example, the New York Stock Exchange opens at 09:30 (EST, UTC offset= −05:00). In California (PST, UTC offset= −08:00) and India (IST, UTC offset= +05:30), the New York Stock Exchange opens at

time in California = 09:30 − (−05:00) + (−08:00) = 06:30; time in India = 09:30 − (−05:00) + (+05:30) = 20:00.

These calculations become more complicated near the time switch to or from daylight saving time, as the UTC offset for the area becomes a function of UTC time.

The time differences may also result in different dates. For example, when it is 22:00 on Monday in Egypt (UTC+02:00), it is 01:00 on Tuesday in Pakistan (UTC+05:00).

The table "Time of day by zone" gives an overview on the time relations between different zones.

Nautical time zones

Since the 1920s, a nautical standard time system has been in operation for ships on the high seas. As an ideal form of the terrestrial time zone system, nautical time zones consist of gores of 15° offset from GMT by a whole number of hours. A nautical date line follows the 180th meridian, bisecting one 15° gore into two 7.5° gores that differ from GMT by ±12 hours.

However, in practice each ship may choose what time to observe at each location. Ships may decide to adjust their clocks at a convenient time, usually at night, not exactly when they cross a certain longitude. Some ships simply remain on the time of the departing port during the whole trip.

Skewing of time zones

Ideal time zones, such as nautical time zones, are based on the mean solar time of a particular meridian in the middle of that zone with boundaries located 7.5 degrees east and west of the meridian. In practice, however, many time zone boundaries are drawn much farther to the west, and some countries are located entirely outside their ideal time zones.

For example, even though the Prime Meridian (0°) passes through Spain and France they use the mean solar time of 15 degrees east (Central European Time) rather than 0 degrees (Greenwich Mean Time). France previously used GMT, but was switched to CET (Central European Time) during the German occupation of the country during World War II and did not switch back after the war. Similarly, prior to World War II, the Netherlands observed "Amsterdam Time", which was twenty minutes ahead of Greenwich Mean Time. They were obliged to follow German time during the war, and kept it thereafter. In the mid-1970s the Netherlands, as other European states, began observing daylight saving (summer) time.

One reason to draw time zone boundaries far to the west of their ideal meridians is to allow the more efficient use of afternoon sunlight. Some of these locations also use daylight saving time, further increasing the difference to local solar time. As a result, in summer, solar noon in the Spanish city of Vigo occurs at 14:41 clock time. This westernmost area of continental Spain never experiences sunset before 18:00 clock time, even in winter, despite lying 42 degrees north of the equator. Near the summer solstice, Vigo has sunset times after 22:00, similar to those of Stockholm, which is in the same time zone and 17 degrees farther north. Stockholm has much earlier sunrises, though.

In the United States, the reasons were more historical and business-related. In Midwestern states, like Indiana and Michigan, those living in Indianapolis and Detroit wanted to be on the same time zone as New York City to simplify communications and transactions.

A more extreme example is Nome, Alaska, which is at 165°24′W longitude – just west of center of the idealized Samoa Time Zone (165°W). Nevertheless, Nome observes Alaska Time (135°W) with DST so it is slightly more than two hours ahead of the sun in winter and over three in summer. Kotzebue, Alaska, also near the same meridian but north of the Arctic Circle, has two sunsets on the same day in early August, one shortly after midnight at the start of the day, and the other shortly before midnight at the end of the day. Consequently, in early May, in Kotzebue one day does not have sunset.

China extends as far west as 73°E, but all parts of it use UTC+08:00 (120°E), so solar "noon" can occur as late as 15:00 in western portions of China such as Xinjiang. The Afghanistan-China border marks the greatest terrestrial time zone difference on Earth, with a 3.5 hour difference between Afghanistan's UTC+4:30 and China's UTC+08:00.

Daylight saving time

Many countries, and sometimes just certain regions of countries, adopt daylight saving time (DST), also known as summer time, during part of the year. This typically involves advancing clocks by an hour near the start of spring and adjusting back in autumn ("spring forward", "fall back"). Modern DST was first proposed in 1907 and was in widespread use in 1916 as a wartime measure aimed at conserving coal. Despite controversy, many countries have used it off and on since then; details vary by location and change occasionally. Countries around the equator usually do not observe daylight saving time, since the seasonal difference in sunlight there is minimal.

Computer systems

Many computer operating systems include the necessary support for working with many or all possible local times. Internally, operating systems typically use UTC as their basic time-keeping standard and convert local times, including daylight savings time, to and from UTC.

Web servers presenting web pages primarily for an audience in a single time zone or a limited range of time zones typically show times as a local time, perhaps with UTC time in brackets. More internationally oriented websites may show times in UTC only or using an arbitrary time zone. For example, the international English-language version of CNN includes GMT and Hong Kong Time, whereas the US version shows Eastern Time. US Eastern Time and Pacific Time are also used fairly commonly on many US-based English-language websites with global readership. The format is typically based in the W3C Note "datetime".

Email systems and other messaging systems (IRC chat, etc.) time-stamp messages using UTC, or else include the sender's time zone as part of the message, allowing the receiving program to display the message's date and time of sending in the recipient's local time.

Database records that include a time stamp typically use UTC, especially when the database is part of a system that spans multiple time zones. The use of local time for time-stamping records is not recommended for time zones that implement daylight saving time because once a year there is a one-hour period when local times are ambiguous.

Calendar systems nowadays usually tie their time stamps to UTC, and show them differently on computers that are in different time zones. That works when having telephone or internet meetings. It works less well when travelling, because the calendar events are assumed to take place in the time zone the computer or smartphone was on when creating the event. The event can be shown at the wrong time. For example, if a Los Angeles resident visits New York and before the journey makes a calendar entry for the return flight at 9 am (which the computer assumes is Los Angeles time), the calendar entry will be at noon if taking the computer's new New York time zone. Calendaring software must also deal with daylight saving time (DST), usually done so calendar entries made before the shift are shown the same after it. If, for political reasons, the begin and end dates of daylight saving time are changed, calendar entries should stay the same in local time, even though they may shift in UTC time.

Operating systems

Unix

Unix-like systems, including Linux and macOS, keep system time in Unix time format, representing the number of seconds that have elapsed since 00:00:00 Coordinated Universal Time (UTC) on Thursday, January 1, 1970, excluding leap seconds. Unix time is usually converted to local time when displayed to the user, and times specified by the user in local time are converted to Unix time. The conversion takes into account the time zone and daylight saving time rules; by default the time zone and daylight saving time rules are set up when the system is configured, though individual processes can specify time zones and daylight saving time rules using the TZ environment variable. This allows users in multiple time zones, or in the same time zone but with different daylight saving time rules, to use the same computer, with their respective local times displayed correctly to each user. Information about time zones and daylight saving time rules most commonly comes from the IANA time zone database. Many systems, including anything using the GNU C Library, a C library based on the BSD C library, or the System V Release 4 C library, can make use of the IANA time zone database.

Microsoft Windows

Windows-based computer systems prior to Windows 95 and Windows NT used local time, but Windows 95 and later, and Windows NT, base system time on UTC. They allow a program to fetch the system time as UTC, represented as a year, month, day, hour, minute, second, and millisecond; Windows 95 and later, and Windows NT 3.5 and later, also allow the system time to be fetched as a count of 100 ns units since 1601-01-01 00:00:00 UTC. The system registry contains time zone information that includes the offset from UTC and rules that indicate the start and end dates for daylight saving in each zone. Interaction with the user normally uses local time, and application software is able to calculate the time in various zones. Terminal Servers allow remote computers to redirect their time zone settings to the Terminal Server so that users see the correct time for their time zone in their desktop/application sessions. Terminal Services uses the server base time on the Terminal Server and the client time zone information to calculate the time in the session.

Programming languages

Java

While most application software will use the underlying operating system for time zone and daylight saving time rule information, the Java Platform, from version 1.3.1, has maintained its own database of time zone and daylight saving time rule information, based on the IANA time zone database. This database is updated whenever time zone or daylight saving time rules change. Oracle provides an updater tool for this purpose.

As an alternative to the information bundled with the Java Platform, programmers may choose to use the Joda-Time library. This library includes its own data based on the IANA time zone database.

As of Java 8 there is a new date and time API that can help with converting times.

JavaScript

Traditionally, there was very little in the way of time zone support for JavaScript. Essentially the programmer had to extract the UTC offset by instantiating a time object, getting a GMT time from it, and differencing the two. This does not provide a solution for more complex daylight saving variations, such as divergent DST directions between northern and southern hemispheres.

ECMA-402, the standard on Internationalization API for JavaScript, provides ways of formatting Time Zones. However, due to size constraint, some implementations or distributions do not include it.

Perl

The DateTime object in Perl supports all entries in the IANA time zone database and includes the ability to get, set and convert between time zones.

PHP

The DateTime objects and related functions have been compiled into the PHP core since 5.2. This includes the ability to get and set the default script time zone, and DateTime is aware of its own time zone internally. PHP.net provides extensive documentation on this. As noted there, the most current time zone database can be implemented via the PECL timezonedb.

Python

The standard module datetime included with Python stores and operates on the time zone information class tzinfo. The third party pytz module provides access to the full IANA time zone database. Negated time zone offset in seconds is stored time.timezone and time.altzone attributes. From Python 3.9, the zoneinfo module introduces timezone management without need for third party module.

Smalltalk

Each Smalltalk dialect comes with its own built-in classes for dates, times and timestamps, only a few of which implement the DateAndTime and Duration classes as specified by the ANSI Smalltalk Standard. VisualWorks provides a TimeZone class that supports up to two annually recurring offset transitions, which are assumed to apply to all years (same behavior as Windows time zones). Squeak provides a Timezone class that does not support any offset transitions. Dolphin Smalltalk does not support time zones at all.

For full support of the tz database (zoneinfo) in a Smalltalk application (including support for any number of annually recurring offset transitions, and support for different intra-year offset transition rules in different years) the third-party, open-source, ANSI-Smalltalk-compliant Chronos Date/Time Library is available for use with any of the following Smalltalk dialects: VisualWorks, Squeak, Gemstone, or Dolphin.

Time in outer space

Orbiting spacecraft may experience many sunrises and sunsets, or none, in a 24-hour period. Therefore, it is not possible to calibrate the time with respect to the Sun and still respect a 24-hour sleep/wake cycle. A common practice for space exploration is to use the Earth-based time of the launch site or mission control, synchronizing the sleeping cycles of the crew and controllers. The International Space Station normally uses Coordinated Universal Time (UTC).

Timekeeping on Mars can be more complex, since the planet has a solar day of approximately 24 hours and 40 minutes, known as a sol. Earth controllers for some Mars missions have synchronized their sleep/wake cycles with the Martian day, when specifically solar-powered rover activity occurs.