Week date representations are in the format as shown in the adjacent box. [YYYY] indicates the ISO week-numbering year which is slightly different from the traditional "Gregorian calendar year (see below). [Www] is the "week number prefixed by the letter W, from W01 through W53. [D] is the weekday number, from 1 through 7, beginning with Monday and ending with Sunday.
There are several mutually equivalent and compatible descriptions of week 01:
As a consequence, if 1 January is on a Monday, Tuesday, Wednesday or Thursday, it is in week 01. If 1 January is on a Friday, Saturday or Sunday, it is in week 52 or 53 of the previous year (there is no week 00). 28 December is always in the last week of its year.
The week number can be described by counting the Thursdays: week 12 contains the 12th Thursday of the year.
The ISO week-numbering year starts at the first day (Monday) of week 01 and ends at the Sunday before the new ISO year (hence without overlap or gap). It consists of 52 or 53 full weeks. The first ISO week of a year may have up to three days that are actually in the Gregorian calendar year that is ending; if three, they are Friday, Saturday, and Sunday. Similarly, the last ISO week of a year may have up to three days that are actually in the Gregorian calendar year that is starting; if three, they are Monday, Tuesday and Wednesday. The Thursday of each ISO week is always in the Gregorian calendar year denoted by the ISO week-numbering year.
An "ordinal date is a simple form for occasions when the arbitrary nature of week and month definitions are more of an impediment than an aid, for instance, when comparing dates from different calendars. As represented above, [YYYY] indicates a year. [DDD] is the day of that year, from 001 through 365 (366 in "leap years). For example, "1981-04-05" is also "1981-095".
This format is used with simple hardware systems that have a need for a date system, but where including full calendar calculation software may be a significant nuisance. This system is sometimes referred to as "Julian Date", but this can cause confusion with the astronomical "Julian day, a sequential count of the number of days since day 0 beginning 1 January 4713 BC Greenwich noon, Julian proleptic calendar (or noon on ISO date -4713-11-24 which uses the Gregorian proleptic calendar with a year ).
ISO 8601 uses the "24-hour clock system. The basic format is [hh][mm][ss] and the extended format is [hh]:[mm]:[ss].
So a time might appear as either "134730" in the basic format or "13:47:30" in the extended format.
Either the seconds, or the minutes and seconds, may be omitted from the basic or extended time formats for greater brevity but decreased accuracy: [hh]:[mm], [hh][mm] and [hh] are the resulting reduced accuracy time formats.
"Midnight is a special case and may be referred to as either "00:00" or "24:00". The notation "00:00" is used at the beginning of a calendar day and is the more frequently used. At the end of a day use "24:00". "2007-04-05T24:00" is the same instant as "2007-04-06T00:00" (see Combined date and time representations below).
Decimal fractions may be added to any of the three time elements. However, a fraction may only be added to the lowest order time element in the representation. A "decimal mark, either a "comma or a "dot (without any preference as stated in resolution 10 of the 22nd General Conference CGPM in 2003, but with a preference for a "comma according to ISO 8601:2004) is used as a separator between the time element and its fraction. To denote "14 hours, 30 and one half minutes", do not include a seconds figure. Represent it as "14:30,5", "1430,5", "14:30.5", or "1430.5". There is no limit on the number of decimal places for the decimal fraction. However, the number of decimal places needs to be agreed to by the communicating parties.
"Time zones in ISO 8601 are represented as local time (with the location unspecified), as "UTC, or as an offset from UTC.
If no UTC relation information is given with a time representation, the time is assumed to be in local time. While it may be safe to assume local time when communicating in the same time zone, it is ambiguous when used in communicating across different time zones. Even within a single geographic time zone, some local times will be ambiguous if the region observes "daylight saving time. It is usually preferable to indicate a time zone (zone designator) using the standard's notation.
If the time is in "UTC, add a Z directly after the time without a space. Z is the zone designator for the zero UTC offset. "09:30 UTC" is therefore represented as "09:30Z" or "0930Z". "14:45:15 UTC" would be "14:45:15Z" or "144515Z".
UTC time is also known as "Zulu time, since Zulu is the "NATO phonetic alphabet word for Z.
The "offset from UTC is appended to the time in the same way that 'Z' was above, in the form ±[hh]:[mm], ±[hh][mm], or ±[hh]. So if the time being described is one hour ahead of UTC (such as the time in "Berlin during the winter), the zone designator would be "+01:00", "+0100", or simply "+01". To represent a time behind UTC the offset is negative. For example, the time in "New York during standard (not daylight saving) hours is "UTC−05:00. For other time offsets see "List of UTC time offsets. To represent a negative offset, ISO 8601 specifies using either a hyphen–minus or a "minus sign character. If the interchange character set is limited and does not have a minus sign character, then the hyphen–minus should be used. "ASCII does not have a minus sign, so its hyphen–minus character (code is 45 decimal or 2D hexadecimal) would be used. If the character set has a minus sign, then that character should be used. "Unicode has a minus sign, and its character code is U+2212 (2212 hexadecimal); the "HTML character entity invocation is
−. Using the minus sign conflicts with similar standards["citation needed], so ISO 8601 implementations will probably accept both hyphen–minus and minus sign characters["citation needed] .
The following times all refer to the same moment: "18:30Z", "22:30+04", "1130−0700", and "15:00−03:30". "Nautical time zone letters are not used with the exception of Z. To calculate UTC time one has to subtract the offset from the local time, e.g. for "15:00−03:30" do 15:00 − (−03:30) to get 18:30 UTC.
An offset of zero, in addition to having the special representation "Z", can also be stated numerically as "+00:00", "+0000", or "+00". However, it is not permitted to state it numerically with a negative sign, as "−00:00", "−0000", or "−00". The section dictating sign usage (section 3.4.2 in the 2004 edition of the standard) states that a plus sign must be used for a positive or zero value, and a minus sign for a negative value. Contrary to this rule, RFC 3339, which is otherwise a profile of ISO 8601, permits the use of "-00", with the same denotation as "+00" but a differing connotation.
ISO 8601 permits the hyphen (-) to be used as the minus (−) character when the character set is limited. In contrast, RFC 3339 explicitly requires the hyphen (-) symbol to represent negative offsets and does not allow for use of the minus (−) symbol.
A single point in time can be represented by concatenating a complete date expression, the letter T as a delimiter, and a valid time expression. For example, "2007-04-05T14:30".
If a time zone designator is required, it follows the combined date and time. For example, "2007-04-05T14:30Z" or "2007-04-05T12:30-02:00".
Either basic or extended formats may be used, but both date and time must use the same format. The date expression may be calendar, week, or ordinal, and must use a complete representation. The time may be represented using a specified reduced accuracy format. It is permitted to omit the 'T' character by mutual agreement.
Durations are a component of time intervals and define the amount of intervening time in a time interval. They should only be used as part of a time interval as prescribed by the standard. Time intervals are discussed in the next section.
Durations are represented by the format P[n]Y[n]M[n]DT[n]H[n]M[n]S or P[n]W as shown to the right. In these representations, the [n] is replaced by the value for each of the date and time elements that follow the [n]. Leading zeros are not required, but the maximum number of digits for each element should be agreed to by the communicating parties. The capital letters P, Y, M, W, D, T, H, M, and S are designators for each of the date and time elements and are not replaced.
For example, "P3Y6M4DT12H30M5S" represents a duration of "three years, six months, four days, twelve hours, thirty minutes, and five seconds".
Date and time elements including their designator may be omitted if their value is zero, and lower order elements may also be omitted for reduced precision. For example, "P23DT23H" and "P4Y" are both acceptable duration representations.
To resolve ambiguity, "P1M" is a one-month duration and "PT1M" is a one-minute duration (note the time designator, T, that precedes the time value). The smallest value used may also have a decimal fraction, as in "P0.5Y" to indicate half a year. This decimal fraction may be specified with either a "comma or a "full stop, as in "P0,5Y" or "P0.5Y". The standard does not prohibit date and time values in a duration representation from exceeding their "carry over points" except as noted below. Thus, "PT36H" could be used as well as "P1DT12H" for representing the same duration. But keep in mind that "PT36H" is not the same as "P1DT12H" when switching from or to "Daylight saving time.
Alternatively, a format for duration based on combined date and time representations may be used by agreement between the communicating parties either in the basic format PYYYYMMDDThhmmss or in the extended format P[YYYY]-[MM]-[DD]T[hh]:[mm]:[ss]. For example, the first duration shown above would be "P0003-06-04T12:30:05". However, individual date and time values cannot exceed their "moduli (e.g. a value of 13 for the month or 25 for the hour would not be permissible).
A time interval is the intervening time between two time points. The amount of intervening time is expressed by a duration (as described in the previous section). The two time points (start and end) are expressed by either a combined date and time representation or just a date representation.
There are four ways to express a time interval:
Of these, the first three require two values separated by an interval designator which is usually a solidus (more commonly referred to as a "forward slash "/"). Section 4.4.2 of the standard notes that: "In certain application areas a double hyphen is used as a separator instead of a solidus." The standard does not define the term "double hyphen", but previous versions used notations like "2000--2002". Use of a double hyphen instead of a solidus allows inclusion in computer "filenames. A solidus is a "reserved character and not allowed in a filename in common operating systems.
For <start>/<end> expressions, if any elements are missing from the end value, they are assumed to be the same as for the start value including the time zone. This feature of the standard allows for concise representations of time intervals. For example, the date of a two-hour meeting including the start and finish times could be simply shown as "2007-12-14T13:30/15:30", where "/15:30" implies "/2007-12-14T15:30" (the same date as the start), or the beginning and end dates of a monthly billing period as "2008-02-15/03-14", where "/03-14" implies "/2008-03-14" (the same year as the start).
If greater precision is desirable to represent the time interval, then more time elements can be added to the representation. An interval denoted "2007-11-13/15" can start at any time on 2007-11-13 and end at any time on 2007-11-15, whereas "2007-11-13T09:00/15T17:00" includes the start and end times. To explicitly include all of the start and end dates, the interval would be represented as "2007-11-13T00:00/15T24:00".
Repeating intervals are specified in clause "4.5 Recurring time interval". They are formed by adding "R[n]/" to the beginning of an interval expression, where R is used as the letter itself and [n] is replaced by the number of repetitions. Leaving out the value for [n] means an unbounded number of repetitions. If the interval specifies the start (forms 1 and 2 above), then this is the start of the repeating interval. If the interval specifies the end but not the start (form 3 above), then this is the end of the repeating interval. For example, to repeat the interval of "P1Y2M10DT2H30M" five times starting at "2008-03-01T13:00:00Z", use "R5/2008-03-01T13:00:00Z/P1Y2M10DT2H30M".
ISO 8601:2000 allowed truncation (by agreement), where leading components of a date or time are omitted. Notably, this allowed two-digit years to be used and the ambiguous formats YY-MM-DD and YYMMDD. This provision was removed in ISO 8601:2004.
On the "Internet, the "World Wide Web Consortium (W3C) uses ISO 8601 in defining a profile of the standard that restricts the supported date and time formats to reduce the chance of error and the complexity of software.
RFC 3339 defines a profile of ISO 8601 for use in "Internet protocols and "standards. It explicitly excludes durations and dates before the "common era. The more complex formats such as week numbers and ordinal days are not permitted.
RFC 3339 deviates from ISO 8601 in allowing a zero timezone offset to be specified as "-00:00", which ISO 8601 forbids. RFC 3339 intends "-00:00" to carry the connotation that it is not stating a preferred timezone, whereas the conforming "+00:00" or any non-zero offset connotes that the offset being used is preferred. This convention regarding "-00:00" is derived from earlier RFCs, such as "RFC 2822 which uses it for timestamps in "email headers. RFC 2822 made no claim that any part of its timestamp format conforms to ISO 8601, and so was free to use this convention without conflict.
ISO 8601 is referenced by several specifications, but the full range of options of ISO 8601 is not always used. For example, the various "electronic program guide standards for TV, digital radio, etc. use several forms to describe points in time and durations. The "ID3 audio meta-data specification also makes use of a subset of ISO 8601. The "GeneralizedTime makes use of another subset of ISO 8601.
The "ISO 8601 week date, as of 2006, appeared in its basic form on major brand commercial packaging in the United States. Its appearance depended on the particular packaging, canning, or bottling plant more than any particular brand. The format is particularly useful for quality assurance, so that production errors can be readily traced to work weeks, and products can be correctly targeted for recall.
|Australia||AS ISO 8601-2007|
|Austria||ÖNORM ISO 8601 (replaced ÖNORM EN 28601)|
|Belgium||NBN EN 28601 (1993)|
|Czech Republic||ČSN ISO 8601 (replaced ČSN EN 28601)|
|Denmark||DS/ISO 8601:2005 (replaced DS/EN 28601)|
|"European Norm||EN ISO 8601, EN 28601:1992 (cancelled 7 October 2011)|
|France||NF Z69-200; NF EN 28601:1993-06-01 (cancelled)|
|Germany||DIN ISO 8601:2006-09 (replaced DIN EN 28601:1993-02); related: DIN 5008:2011-04 (replaced DIN 5008:2005-05, DIN 5008:2001-11, DIN 5008:1996-05)|
|Greece||ELOT EN 28601|
|Hungary||MSZ ISO 8601:2003|
|Iceland||IST EN 28601:1992|
|Italy||UNI EN 28601 (1993)|
|Japan||JIS X 0301:2002|
|Korea, Republic of||KS X ISO 8601|
|Latvia||Ministru kabineta noteikumi Nr.916|
|Lithuania||LST ISO 8601:2006 (replaced LST ISO 8601:1997)|
|Netherlands||NEN ISO 8601, NEN EN 28601 (1994), NEN 2772|
|Poland||PN-90/N-01204 (removed, outdated)|
|Portugal||NP EN 28601|
|Russia||ГОСТ ИСО 8601-2001 (current), ГОСТ 7.64-90 (obsolete)|
|South Africa||SANS 8601:2009|
|Spain||UNE EN 28601|
|Sweden||SS-ISO 8601 (replaced SS-EN 28601 (1991))|
|Switzerland||SN ISO 8601:2005-08 (replaced SN-EN 28601:1994)|
|Thailand||TIS 1111:2535 (1992)|
|Turkey||TS ISO 8601|
|Ukraine||ДСТУ ISO 8601:2010|
|United Kingdom||BS ISO 8601:2004, BS EN 28601 (1989-06-30)|
|United States||ANSI INCITS 30-1997 (R2008) and NIST FIPS PUB 4-2|
"" Media related to ISO 8601 at Wikimedia Commons
Annex A ... From that concept representations of all other date and time values were logically derived; thus, ISO 2014, ISO 3307 and ISO 4031 have been superseded.... Identification of a particular date by means of ordinal dates (ISO 2711) and by means of the week numbering system (ISO 2015) were alternative methods that the basic concept of this International Standard could also encompass; thus, ISO 2015 and ISO 2711 have now been superseded.
The Gregorian calendar today serves as an international standard for civil use.
3.5 Expansion ... By mutual agreement of the partners in information interchange, it is permitted to expand the component identifying the calendar year, which is otherwise limited to four digits. This enables reference to dates and times in calendar years outside the range supported by complete representations, i.e. before the start of the year  or after the end of the year .
Truncated representation, as specified in [ISO.8601.2000], Sections 220.127.116.11 d), e), and f), is permitted.
Decimals Score a Point on International Standards ... It soon may be possible to write international standards documents with decimal points in them.
18.104.22.168 ... the decimal fraction shall be divided from the integer part by the decimal sign specified in ISO 31-0, i.e. the comma [,] or full stop [.]. Of these, the comma is the preferred sign.
4.3.2 NOTE: By mutual agreement of the partners in information interchange, the character [T] may be omitted in applications where there is no risk of confusing a date and time of day representation with others defined in this International Standard.