The concept of "Daylight Saving Time" (DST) or "Summer Time" is used as a way of allowing people more sunlight hours in the evening. Not all regions observe summer time: usually those nearer the equator do not need it. Whether summer time is observed and how it is observed varies by jurisdiction.

As the name implies, areas that use some form of "summer time" do so in the summer season. That is, they change their UTC offset forward (usually by one hour) sometime in the spring and the reverse when the observation of summer time ends in the autumn. Since "spring" and "autumn" happen in opposite parts of the year in the northern and southern hemispheres, the starting and ending days are different for time zones in opposite hemispheres.

Observation (or non-observation) of summer time is controlled by national, regional, and sometimes local governments. Regions that otherwise share a UTC offset, even those with similar latitude (or shared borders) can have differing summer time start or stop rules. Sometimes local authorities will make one-time changes to accommodate a special event (such as when hosting the Olympics). Governments sometimes change whether summer time is observed as well as changing when summer time begins or ends.

While other schemes exist, many applications use theIANA Time Zone Database [BCP175] and its associated set of identifiers to define time zones.

Time zones are defined by these considerations:

Local Time Offset Time zones are used to compute the offset ofwall time fromUTC. The local time offset is the difference (positive or negative) between when a given time event is observed in UTC and local time. If all time zones used one-hour offsets, there would be 24 world-wide time zones, ranging between 12 hours before UTC to 11 hours following UTC. However, there are some that use half-hour or even quarter-hour offsets (or even some odd offsets). In addition, some time zones fall outside a single 24-hour span.

Observation of summer time Some times zones include rules for observing daylight-savings or summer time, while others do not. The observation of summer time is defined by a set of rules that include:

• Summer time offset The amount of time added to (or subtracted from) thelocal time offset when summer time is being observed. Nowadays this is always one hour, but other values are theoretically possible (and have been used historically).
• Starting date Usually described as a specific date on a specific calendar, such as the "first Sunday in April"
• Starting time The time of day when the switch occurs, such as "2 AM"
• Ending date Like the starting date, the date on which to switch back to "standard time"
• Ending time The time of day when the switch occurs, such as "2 AM"

Adoption Dates Regions that currently have a specific local time offset and summer time behavior may have had different rules in the past (or plan to adopt new rules in the near future). Correct handling of past time values requires treating such regions as separate time zones.

Adoption dates can be applied to any of the values that define a time zone, such as the amount of summer time offset and the starting/ending dates or times for summer time. For example, prior to 2007, the United States started daylight-savings time at 2 a.m. on the first Sunday in April for each time zone observing daylight-savings. In 2007, the USA changed the start date and time to 2 a.m. on the second Sunday in March.

Korea Standard Time and Japan Standard Time currently use the same UTC offset and neither uses summer time. However, Japan abandoned summer time in 1951, while South Korea used it last in 1988, so an application that tracks time values that reach back that far might need to track these time zones separately.

The most definitive reference for identifying sets of time zone rules is the IANA Timezone Database [BCP175], which is used by systems such as various Linux distributions, Java, CLDR, ICU, and many other systems and libraries. Other systems exist: for example, Microsoft Windows uses its own data set and identifiers.

In the TZ database, time zones are given IDs that usually consist of a region and exemplar city. Regions can be continents (such as Europe or America) or oceans (such as Atlantic or Pacific). An exemplar city is a city in the time zone in question that should be well-known to people using the time zone. The TZ database also supplies aliases for many IDs; for example,Asia/Ulan Bator is equivalent toAsia/Ulaanbaatar. The Common Locale Data Repository [CLDR] can be used to provide a localized form for the IDs: see Appendix J in [UAX35]. Note: some systems, such as Apple Inc.'s MacOS, provide additional exemplar cities.

Specify the use of IANA time zone IDs in standards, protocols, or document formats as the identifier for time zones.

Avoid special purpose time zone IDs, such as those beginning withEtc/.

Usecontinent/city IDs in preference to legacy zone IDs such as those starting withUS/.

Most countries are either small enough in area or, for practical reasons, choose to observe only a single time zone for the entire country. This means that knowing the region or country of the user is frequently sufficient to identify the time zone of the user as well. At the time this document was published, only twenty countries had more than one observed time zone. These countries are: Argentina, Australia, Brazil, Canada, Chile, Democratic Republic of the Congo, Ecuador, France, Greenland, Indonesia, Kazakhstan, Kiribati, Mexico, Micronesia, Mongolia, New Zealand, Portugal, Russia, Spain, and the United States.

Some special cases exist within this list:

• Countries with maritime or overseas possessions Chile, Ecuador, France, New Zealand, and Portugal each have islands or other wide-ranging geographic areas far from the main part of the country. For example, Easter Island is part of Chile, the Galapagos Islands are part of Ecuador, and the Azores are part of Portugal. These offshore possessions are the source of additional time zones in each of these countries.
• France France is a special case of the above. There are several regions that are part of France, even though they might have their own ISO 3166-1 code. These include Reunion Island (in the Indian Ocean) and French Guiana (in South America). Additionally, French Polynesia is divided into three time zones.

Within each of the countries that observe multiple time zones, knowing the current offset and current time will usually allow you to determine the time zone accurately. An exception to this is the United States: there exist some regions, such as Arizona, whose time zone cannot be determined strictly from the current time, country/region code, and offset, although an inferred time zone will always work for current time applications (not future and past times).

Time zones, their rules, offsets, and observation (or non-observation) of summer time are controlled by a variety of international agreements, as well as national, regional, sub-national, and local governments. This can mean that neighboring areas that might otherwise share a UTC offset, even those with similar latitude (or shared borders) can have differing rules, such as those governing daylight-savings. Sometimes local authorities will change the boundaries of a zone or the offset used by a given region. Or they can make one-time changes to accommodate a special event (such as when hosting the Olympics). The time zone database tracks past changes so that applications can accurately computewall time for past and future events.

Because there are many governing bodies acting independently, the time zone database is not stabilized. New rule changes or updates to historical records are introduced into the database as they are made known (such as due to legislative action). There is no specific release cycle: updates can happen at any time. When changes affect future events, computing systems have to be updated lest their clocks show the wrong local time for a given region or compute the wrong results for events affected by the change.

Incremental time measures time using fixed integer units that increase monotonically from a specific point in time called theepoch. Most programming languages and operating environments provide data types and APIs that use incremental time to represent or operate on datetime values. Incremental time is not usually seen directly by users. Instead, the incremental time value is formatted into a familiarwall time representation for human consumption.

The most common form ofincremental time is counted in milliseconds (or, occasionally, nanoseconds) in the Unix Epoch. In this system, the value0 represents midnight, January 1, 1970 in the UTC time zone. Negative numbers represent datetime values earlier than this moment, while positive numbers denote later moments in time. The [ISO8601] representation of this would be1970-01-01T00:00:00.000Z. Examples of this form of incremental time include:

• Java:java.util.Date
• C/C++:time_t
• #"#dfn-timeline" data-link-type="dfn">timeline.

  This also means that incremental datetime values are indepedent of (and generally do not encode) their originating time zone. This is because the monotonic time in the UnixEpoch is the same everywhere at any given instant. Each incremental time value can be transformed for display using variouschronologies, time zone rules or,local time offsets.

  Note

  Not all incremental time values are tied to specificepoch. A system's clock might be counting from the last time the hardware clock was restarted or some other event. Date values close to January 1, 1970 are often due to an incremental time value of0 or due to malfunctions in or failure to set the system clock.

Afield-based time divideswall time into separate field values such as year, month, day, hour, minute, second, etc. Field-based times may or may not be tied to either UTC or the local time zone—or may be indeterminate. Field-based times are also typically tied to a specific calendar (such as the Gregorian calendar). The formats described by the [ISO8601] standard are field-based.

Somefield-based time values are on thetimeline (that is, "zone-dependent" values) while others arefloating time values. It's important to distinguish between these two when working withfield-based time to avoid inappropriate conversion of the value.

Thetm structure in the C programming language is an example of a field-based time.

#include <time.h>#include <stdio.h>int main(void){  struct tm t;  time_t t_of_day;  t.tm_year = 2011-1900; /* 1900 based */  t.tm_mon = 0;   /* January: zero based! */  t.tm_mday = 3;  /* the third */  t.tm_hour = 0;  /* midnight */  t.tm_min = 0;   /* midnight */  t.tm_sec = 0;   /* midnight */  t.tm_isdst = 0; /* no DST in January */  t_of_day = mktime(&t);  /* convert the tm struct to an incremental time_t */  printf(ctime(&t_of_day));  return 0;}

A field-based time may or may not include information about the time zone being used. In a purely numeric representation, such astime_t, sometimes only the current UTC offset is provided.

Afloating time is a date or time value in acalendar that is not a specificinstant in time. Applications and data formats use afloating time value when thewall time is more important to the value than putting the event onto atimeline. Generally, a floating time value will include only the date (2024-01-27) or only the time (13:00:00), but datetime values (2024-01-27T13:00:00.000) are sometimes also needed.

Floating time values are used when a given value's localwall time expression needs to stay constant, regardless of the viewing user's time zone. For example, if your birthdate wereJune 1, 1980 this might be represented as thefloating time1980-06-01. It does not matter if you view this date in Tokyo, London, or San Francisco: you always want the displayed value to remain constant. Time values that float can include things such as hours of operation as a policy, rather than for a specific location.

Floating time values are often serialized in various ISO8601 formats by omitting thelocal time offset (or time zone identifier, such asZ forUTC). Data types for floating time values are less common in programming languages and operating environments. Errors are often the result when a floating time value is deserialized into into anincremental time type, which ties the value to UTC.

For example, the French national holiday Bastille Day (Fête Nationale) is observed on July 14th each year. Thus the 2022 occurence might be represented by the value2022-07-14. However, the observation of the holiday isn't tied to any specific location. Instead, its meaning "floats" based on locally observed midnight.

France has a number of overseas departments which do not share a time zone with Metropolitan France. In this example, we'll look at three French time zones:Europe/Paris,Pacific/Noumea (the time zone used in New Caledonia), andPacific/Tahiti (one of the timezones in French Polynesia).

New Caledonia is one of (but not the) first time zones in France to observe the holiday. Tahiti is one of (but not the) last in France to observe it. The table below shows the dates and times in each of the time zones as Bastille Day is observed around the world. Notice that some of theincremental time values that are "Bastille Day" in one time zone are either before "Bastille Day" starts or after it ends in the other time zones:

Sometimes aproducer will emit afloating time value when theconsumer expects or requires anincremental time value. In other cases, aconsumer might need to convert a local or otherwise incremental time value into a floating date or time.

Tofloat a date or time value means to remove anincremental time value from thetimeline by deleting any associated time zone and zone offset information from the value.

One common reason to float a value is if the data type used to collect or process the value is an incremental type (such as anInstant or JavascriptDate) but the value isn't. For example, if you received a user's birth date as aDate object. Removing the time zone or offset makes it easier to format the value later without the field values changing incorrectly.

Tounfloat a date or time value means to attach afloating time value to thetimeline by adding a time zone or zone offset to the value.

One common reason to unfloat a value is that the serialized value might not contain an offset but the value needs to be compared to other incremental values or displayed to the user in local time.

Values received without a time zone or zone offsetSHOULD generally be treated as if they are in UTC. SpecificationsSHOULD provide guidance on how to handle these values. ImplementationsMAY use some other value for the offset, such as the user agent's local time zone, but only if there is a good reason to do so.

Conversion between or operation on data sets that mix values with and without time zones orzone offsets presents certain problems. If one wishes to write a comparison between the value of afloating time value and a non-floating value, then the two values have to be reconciled to us the same reference point on thetimeline.

2005-06-07T13:14:27Z  2005-06-07T11:00:00

If one wishes to write a comparison between the value of<aDateTime> and<bDateTime>, then the two values must be reconciled to use the same reference point.<aDateTime> uses UTC and can easily be converted to computer time or shifted to another zone offset.<bDateTime> contains no indication of the zone offset. It might be UTC or any other value (currently up to 14 hours different in either direction from UTC).

It is good practice to use a time zone identifier or at least an explicit zone offset wherever possible. If one is not available, use UTC as the implicit zone offset for conversions of this nature. This is because the values are exactly centered in the range of possibilities and because representation internally (as computer time) is usually based on UTC. Since a single reference point has been used it might be possible to unwind the change later even if an erroneous conversion has taken place. When working with multiple documents from various sources, the "implicit" offset of the document may vary widely from that of the implementation doing the processing. If UTC is widely used, the chances of error are reduced.

Content and query authors are warned that comparing or processing data sets that contain both date and time values with and without time zones or zone offsets may produce odd results. Such processing should be avoided whenever possible. Generating content that omits zone offset information (where it exists) is a recipe for errors later. Of course, data such as the SQL types cited earlier and which are meant to represent wall time, should continue to omit the zone offset. Query writers can check for the presence (or absence) of zone offset and should do so to modify dates and times explicitly (instead of allowing implicit conversion) whenever possible.

When comparingfloating times toincremental times, use UTC as the time zone.

Incremental time andfield-based time differ in the way certain operations work. For example, incremental times can often be directly compared: their integer values determine which is earlier or later.Field-based times have to be normalized and their individual fields compared.

Field-based times are often optimized to allow for various kinds of adjustments to be made to a value while minimizing the chances for error. For example, to set the date2005-08-30 forward by one day, an implementation can add 'one unit' to the "day" field and adjust the day, month, and year fields as appropriate to the calendar system. In incremental time, a similar operation might be performed by incrementing the value by24 hours * 60 minutes * 60 seconds * 1000 milliseconds, which is one "logical day". However, there can be errors when a particular day has more or fewer seconds in it (such as occur during daylight saving transitions) or when the unit has a variable size, such as when adding a month or a year, since those fields have variable numbers of days in them.

Bear in mind that rolling fields forwards or backwards infield-based times can be tricky. For example, Feburary does not always have the same number of days in it. Or consider the problem of incrementing the month forward by one in the date2011-01-30.

Serializations of date/time values tend to behave as-if they were field-based, in that they provide human-readable values tied to a specificchronology (typically theISO Chronology). The most familiar example of such a serialization scheme is [ISO8601], along with its many flavors and interpretations, such as [RFC3339] or [XMLSchema-2]. The SQL data typesdate,time, andtimestamp arefield-based time values which are intended to be zone offset independent: they are actuallyfloating time values! The SQL data typetimestamp with time zone is actually the type that should be used forincremental time values ("timestamps").

By contrast with SQL types, programming languages tend to useincremental time for their primitive time types. They convert to and from field-based serializations demand. As a result, users might not be clear about the differences between these types or can accidentally create a mixture of different representations. For example, a Java programmer using JDBC might access a field in a SQL query using the classjava.sql.Date. This class represents the value as anincremental time in UTC. This adds information inappropriately tofloating time values or can remove zone-offset information from the originalfield-based time value.

Databases can useincremental time or either zone offset-dependent or independent field-based structures internally. For example, Oracle databases treat atimestamp field as though it is in the local time zone of the database instance. The combination of application and database time zones coupled withimplicit conversions betweenincremental time andfield-based time values can result in date/time values changing meaning without the user intending it.

In [XMLSchema-2], as with SQL, dates and times are expressed usingfield-based time. The date or time can express the zone offset from UTC (for example using a format such as08:00:00+01:00).UTC is indicated by the letterZ (for example08:00:00Z). The zone offset can also be omitted (producing afloating time value).

Properly speaking, an XML Schema date or time value with a zone offset is field-based/zone offset dependent and one without is field-based/floating.

If the two types are mixed, then the interpretation of the zone offset is not adequately specified in XML Schema. In [XPATH-FUNCTIONS], the interpretation is implementation-defined and is based on an implicit zone offset. This is usually either UTC or whatever the local time offset of the host environment is. The presence or absence of the zone offset in the XML Schema serialized representation might not be indicative of the original data's intention because of the confusion described above. Proper comparisons or processing rely on normalizing all date and time values intofloating time or zone offset-dependent (field-based zone-dependent) forms and never mixing the two in a particular operation.

Date/time values often need to be serialized (converted to some string representation) for exchange in various document formats and protocols. Sometimes these serializations can be produced from or used to instantiateincremental time,field-based time, orfloating time datatype values directly. Precisely which serialization to use depends on the application'suse case and available standards. Serializations that use time zone IDs instead of relying on offsets areRECOMMENDED.

YouSHOULD useZonedInstant type for past-only events.

YouMAY useZonedInstant,ZonedLocalDateTime orZonedOffsetDateTime types for past events.

For an application that deals only with events that occurred in the past (with no future events) and for which you need to know what the wall time was, thelocal time offset of the event may be necessary additional data. Note that the time zone also provides thelocal time offset and is, thus, an acceptable substitute.

Once an event is in the past, itslocal time offset toUTC becomes fixed. Therefore an incremental time with an offset can always producewall time in a givenchronology.

Althoughlocal time offset is sufficient, knowing the specific time zone allows the application to reconstruct the time and its relationship to other time values and is usually more convenient when formating the value for display. For example, without the time zone identifier, it's not possible to accurately include the time zone's name or abbreviation into the display.

YouSHOULD useZonedInstant type if your application can have events in the future.

For an application that deals with both past and future events (for example, if you have a calendar or a meeting schedule), you will need the time zone (and not merely thelocal time offset) to ensure proper time computation. This is because a future event'swall time depends on time zone-related information, such as summer time transitions.

One issue with future events is that rules for the event's associated time zone canchange from time to time and these changes can require an application to update affected data records in order to meet the user’s expectations. This is because many systems actually store or depend on using anincremental time value for date/time related operations (such as scheduling or notifications). When the time zone rules change, the corresponding the incremental time value needs to be checked or updated if thewall time of the event is expected to stay the same. Seeabove for an example.

A recurring event, such as a regular meeting, is usually defined by a set of rules that express a user's intent. In many cases, the user intends for the event to recur at a specific localwall time in a specific time zone. Each iteration is thus apast or future event.

Each iteration of the event will need to compute a specific (incremental time value) start time and this value will depend on the governing time zone's rules regardinglocal time offset, summer time transitions, and the like. It is important to use the time zone to perform these computations, as this avoids problems with assuming that the number of units between events (such as hours in a week or minutes in a day) is fixed. It can also help avoidghost times.

YouSHOULD use the appropriate floating time type, such asLocalDateTime (for values with both date and time),LocalDate (for date values), orLocalTime (for time-only values) for values that are not tied to a specific offset or time zone rules.

If your application deals with a date or time value that is not tied to a specific local interpretation or which needs to be interpreted as a different range of incremental time values in different locations, serializing the value without an offset or time zone identifer communicates that the value is afloating time.

Such applications are more common than they first appear. We've already seen examples in this document, such as a list of holidays or a user's birth date. Any "anniversary" type of date (hire date, termination date, wedding date, etc.) is generally best representated afloating time value. Another application is when you collect statistics usinginstants but need to group them into durable time buckets byfloating the values.

Whenever possible, useUTC or choose a consistent time zone when creating time-based content or data value so that values from discrete sources can be compared more readily.

It is much easier to work with and debug data values that can be compared visually. When values use different offsets or time zones, the user has to mentally translate the value. This can lead to mistakes. When you read the "mixed offset" list of timestamps below, is it easy to spot that the last two items are identical or that the first three are different?

Bear in mind best practices to assist users in selecting their time zone, including keeping track of their preferences.

Some best practices when implementing time zone selection and management:

• Allow the user to choose a time zone and keep it associated with the user's session or profile if possible.
• Consider using exemplar cities to help users identify the time zone.
• Use the country as a hint, since most countrieshave only a single time zone.
• Omit historical time zones whenever possible.
• Use IP-geolocation, cellular radio country code, GPS data, or other external data sources if available.

One quirk of timekeeping is the need for leap seconds. The Earth's rotation is not even and, in general, is slowing down. To keepobserved time andincremental time in sync, the [International Earth Rotation Service] occasionally mandates a "leap second". A leap second usually occurs once or sometimes twice per year and always takes the form of an additional second added to the last minute of the day. Usually the leap second is added to December 31st or June 30th.

Most incremental time values (do not keep track of leap seconds in their incremental time values. What happens is:

1. Eventually, system clocks are updated externally by the user or via a service such as NTP. Most computer clocks exhibit some amount of clock drift anyway, so this sort of maintenance is not unusual.
2. No list is kept of past or future leap seconds (and no list exists for dates preceding the advent of leap seconds in 1972), so software often doesn't include leap seconds when calculating the difference between two time values. For example, the difference between 12:00:00 Noon on December 31st and 12:00:00 Noon on the following January 1st will always be 86400 seconds, even if a leap second was mandated for the intervening midnight.
3. There may be no way to represent a leap second time value using your local incremental units and may not be a means of representing a leap second using field-based units. For example, while Java'sjava.util.Calendar class allows for a "61st" second of a minute to accommodate leap seconds, if you set a Java Calendar to the equivalent ofDecember 31, 2008 23:59:60 UTC (a particular leap second value) and then convert that to ajava.util.Date in order to print it out, you might see: "January 1, 2009 00:00:00 UTC". This is because theDate object is anincremental time and the code formatting the value doesn't know about the leap second.

If your application cares about or is sensitive to leap seconds, special care must be taken to deal with the loss of leap second precision.