Never in the history of mankind has there been so much information about Time zone as there is today thanks to the internet. However, this access to everything related to Time zone is not always easy. Saturation, poor usability, and the difficulty to discern between correct and incorrect information about Time zone are often difficult to overcome. That's what motivated us to create a reliable, safe and effective site.
It was clear to us that in order to achieve our goal, it was not enough to have correct and verified information about Time zone. Everything we had collected about Time zone also had to be presented in a clear, readable way, in a structure that facilitated the user experience, with a clean and efficient design, and that prioritised loading speed. We are confident that we have achieved this, although we are always working to make small improvements. If you have found what you have found useful about Time zone and you have felt comfortable, we will be very happy if you come back to wikious.com whenever you want and need to.
In the table below, the locations that use daylight saving time (DST) are listed in their UTC offset when DST is not in effect. When DST is in effect, approximately during spring and summer, their UTC offset is increased by one hour (except for Lord Howe Island, where it is increased by 30 minutes). For example, during the DST period California observes UTC−07:00 and the United Kingdom observes UTC+01:00.
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 of time for every degree of longitude, so 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.
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.
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 then 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, that is 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.
Charles F. Dowd proposed a system of hourly standard time zones for North American railroads around 1863, 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., but by 1872 the first was centered on 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. Instead, U.S. and Canadian railroads implemented 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 all 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
"World time" redirects here. For the global time standard, see Universal Time.
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 and reinstated in 2014.
If a time is in Coordinated Universal Time (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).
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
Difference between sun time and clock time during daylight saving time:
1h ± 30 min behind
0h ± 30m
1h ± 30 m ahead
2h ± 30 m ahead
3h ± 30 m ahead
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 (DST), 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.
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.
A visualization of the mismatch between clock time and solar time in different locations. In blue areas, clock time lags behind solar time; in red areas, the reverse is true. The two are synchronized in the white areas.
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.
Many computer operating systems include the necessary support for working with all (or almost all) possible local times based on the various time zones. Internally, operating systems typically use UTC as their basic time-keeping standard, while providing services for converting local times to and from UTC, and also the ability to automatically change local time conversions at the start and end of daylight saving time in the various time zones. (See the article on daylight saving time for more details on this aspect).
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 New Yorker plans to meet someone in Los Angeles at 9 am, and makes a calendar entry at 9 am (which the computer assumes is New York time), the calendar entry will be at 6 am if taking the computer's time zone. There is also an option in newer versions of Microsoft Outlook to enter the time zone in which an event will happen, but often not in other calendar systems. Calendaring software must also deal with daylight saving time (DST). 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. In Microsoft Outlook, time stamps are therefore stored and communicated without DST offsets. Hence, an appointment in London at noon in the summer will be represented as 12:00 (UTC+00:00) even though the event will actually take place at 13:00 UTC. In Google Calendar, calendar events are stored in UTC (although shown in local time) and might be changed by a time-zone changes, although normal daylight saving start and end are compensated for (similar to much other calendar software).
Most Unix-like systems, including Linux and Mac OS X, keep system time in time_t format, representing the number of seconds (excluding leap seconds) that have elapsed since 00:00:00 Coordinated Universal Time (UTC) on Thursday, January 1, 1970. By default the external representation is as UTC (Coordinated Universal Time), though individual processes can specify time zones using the TZenvironment variable. This allows users in multiple time zones to use the same computer, with their respective local times displayed correctly to each user. Time zone information most commonly comes from the IANA time zone database. In fact, many systems, including anything using the GNU C Library, can make use of this database.
Windows-based computer systems prior to Windows 2000 used local time, but Windows 2000 and later can use UTC as the basic system time. 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.
While most application software will use the underlying operating system for time zone information, the Java Platform, from version 1.3.1, has maintained its own time zone database. This database is updated whenever time zone rules change. Oracle provides an updater tool for this purpose.
As an alternative to the time zone information bundled with the Java Platform, programmers may choose to use the Joda-Time library. This library includes its own time zone 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 time zones.
Java 8 Date Time
The DateTime object in Perl supports all time zones in the Olson DB and includes the ability to get, set and convert between time zones.
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.
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.
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 Greenwich Mean Time (GMT).
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, because solar-powered rover activity on the surface was tied to periods of light and dark.