This article gently introduces the concepts behind some basic terminology you will encounter when reading other articles that deal with time zones and handling of dates and times on the Web.
The document Working with Time Zones provides greater detail on each of these topics, as well as guidelines on handling of times and dates on the Web. Read that for a more in-depth treatment.
UTC is also known as GMT (Greenwich Mean Time). There are some subtle differences between the two, but none that the average person would notice.
Universal Coordinated Time (UTC) is the basis for modern timekeeping. Among other things, it provides a common baseline for converting between incremental and local time.
The time zone offset for UTC is 0. UTC is often indicated in field-based formats using Z.
When you write a time using a field-based format you divide the date and/or time into separate field values such as year, month, day, hour, minute, second, etc. such as 2016-09-11T06:10:32. Contrast this with an alternative way to express the same time, 1465621816590, which is not field-based and is rather hard to read.
Field-based times may or may not be tied to either UTC or the local time zone – or they may be indeterminate. Field-based times are also typically tied to a specific calendar (such as the Gregorian calendar).
The formats described by the ISO 8601 standard are field-based.
Incremental time is a way of representing time in computers that is based on a progression of fixed integer units that increase monotonically from a specific point in time (called the "epoch").
Java (and many other systems) count time as the number of milliseconds since midnight (00:00 a.m.) on January 1, 1970 in UTC (less all of the intervening leap seconds). Other systems use different units and/or epochs.
For example, at one point while writing this paragraph the incremental time for JavaScript in my browser was 1465621816590 (ie. 11 June, 2016 at 6.10am BST).
Most programming languages and operating environments provide or use incremental time for working with time values. However, incremental time is not usually seen directly by users, but is typically mapped to a field-based time format for interchange or for human consumption.
Wall time or local time is a moment in time, that can be mapped to a specific point in incremental time if you apply any relevant time zone information, but it corresponds to what a person would recognise the time to be if they looked at a clock and/or calendar mounted on a wall in a particular place.
So, for example, while writing the previous section I may have glanced at the time displayed by my computer and seen Sat 11 Jun 06:10. If I apply knowledge about how that time relates to UTC (in my case, adjusting by one hour to account for British Summer Time) I can convert that to the incremental time 1465621816590.
It's also possible to convert that to a wall time in another location, such as San Francisco, where someone looking at their computer's time display at the same time would have seen Fri 10 Jun 22:10.
Some time values are not mapped to a specific moment in incremental time. Instead, they represent a nominal time which is described in the same way in all time zones around the world.
For example, Saturday 11 June 2016 happens to be the date of the British Queen's official 90th birthday. The specific time when 11th June starts or ends in Britain may actually be on Friday or Sunday in other countries, because their clocks are set differently, but the date of the event is always referred to as Saturday 11 June.
We refer to these sorts of time values as floating times because they are not fixed to a specific incremental time value. When you apply time zone information to floating times they produce a range of acceptable incremental time values.
Floating times are not attached and should never be attached to a particular time zone.
Other examples of floating time events include the publication date for an issue of a newspaper, the date the Rio Olympics starts, the time the New Year starts, office hours set to "9 to 5" regardless of time zone, and so on.
A time zone is a set of rules for determining the local time (wall time) as it relates to incremental time (as used in most computing systems) for a particular geographical region, and vice versa.
Time zone rules have to take into account zone offsets plus any daylight savings modifications to wall time that apply.
A zone offset is an amount that is added to or subtracted from UTC based on the location of the event around the world relative to the prime meridian. Usually offsets are at one-hour intervals, but offsets can also include other differences, such as 30 or 45 minutes.
A common way to express a zone offset in field-based formats is with +/- followed by the offset. So for example, Japan is 9 hours ahead of UTC, so you may see a time written as 2016-06-11 05:10+09:00.
Note, importantly, that the zone offset does not help you convert times to wall time where daylight savings time is in force.
Daylight Saving Time (DST) or "Summer Time" was adopted as a way of allowing people more sunlight hours in the evening.
DST varies from country to country (not to mention locality-to-locality) and often has special one-off changes to accommodate special events. Not all regions observe DST: usually those closer to the equator do not need it.
In converting times it is important to know when DST was introduced, and sometimes abandoned, for the local area, as well as on what dates DST starts and ends (which can vary from year to year).
For example, Korea Standard Time and Japan Standard Time currently use the same zone offset and neither uses daylight saving. However, Japan abandoned DST 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.
Time zone identifiers allow you to refer to a particular difference from UTC that includes both zone offsets and daylight savings time.
The most definitive reference for identifying sets of time zone rules is the TZ database (also known as the Olson time zone database), which is used by systems such as various commercial UNIX operating systems, Linux, 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 typically consist of a region and exemplar city. An exemplar city is a city in the time zone in question that should be well-known to people using the time zone. For example, the U.S. Pacific time zone has a TZ database ID of America/Los_Angeles. The TZ database also supplies aliases for many IDs; for example, Asia/Ulan Bator is equivalent to Asia/Ulaanbaatar.
The Common Locale Data Repository (CLDR) can be used to provide a localized form for the IDs. Note that some systems, such as Apple's Mac OS, provide additional exemplar cities.
The Gregorian calendar is the most widely used way of representing civil time. It is a solar calendar, with years usually consisting of 365 days, plus the concept of a "leap year". This adds an additional day every 4 years, except when the year is evenly divisible by 100 (unless the year is also evenly divisible by 400).
There are numerous other calendars in use around the world, some of which are lunar calendars, some that are based on a different start date than the Gregorian calendar, and some that are reset each time a prominent person dies. Often these calendars are still used for religious purposes, but sometimes you will also find them being used in newspapers and emails, or for birth dates.
There are technologies, such as ICU or Dojo, that support conversion between different calendaring systems.
The following show examples of field-based times for terms used in the HTML5 spec, as a handy reference.
Authoring web pages
Developing specifications