Talk:ISO 8601/Archive 1

Archive 1

Archive 2

Archive 3

Start of week

It is odd that Europeans lately are looking at ancient traditions that were brought to America from Europe and thinking they originated in the USA. The USA is more traditional than Europe is; that is why Sunday is still considered the first day of the week here. -- Mike Hardy

I don't know where you got that idea; in much (but not all) of Europe, calendars show Sunday as the first day. Also, as in Genesis, "... and on the seventh day he rested" ... the basis of Saturday being the Jewish sabbath. Sunday, in the Christian New Testament bible, is the day of the resurrection, a new beginning, and so Sunday is considered the first day of the week.

However; in Asia, which more recently adopted the seven-day-week, refers to Monday as "Day 1" and also the airlines use the number "1" for Monday and also, as noted, ISO refers to Monday as day 1. Does anyone here know where the concept of Monday as "the first day of the week" originated?

--Enquire (talk) 22:09, 13 July 2008 (UTC)

I don't think the old version was claiming that the tradition originated in the US, just that it was followed there. Anyway, it's not a big deal. --Camembert

Hm, is this view that Monday is day 1 really more "modern" than the view that Sunday is day 1? I mean, it must come from somewhere, this view. --Camembert

• And on the seventh day, he rested. Because of the Biblical reference, the seventh day is usually referred to as the "Sabbath". Logically, that would make the next day the first day of the week, but the creators of the calendars chose to use the Sabbath as the first day of the week, probably to give more emphasis to the function of their respective organizations. The ISO shows the first day of the week as the first workday of the week. Their intent was probably functional, not Biblical, but the effect is the same. On the seventh day, you rest.--James thirteen (talk) 16:06, 26 April 2008 (UTC)

I'll bet you $1 it originated no more than 150 years ago. -- Mike Hardy

Sunday is the common start of the week in the US because the Gregorian Calendar was the official calendar in the US before switching to the ISO calendar. Sunday is the first day of the week in the Gregorian calendar (and the Islamic and Jewish calendars). This is why I was disappointed when I found that the US silently adopted the ISO calendar with its different start of week. I assume that most Western European countries (and others?) also switched from the Gregorian to the ISO calendar in the late 1980's or 1990's? From the languages that have number names for some days of the week it seems common for Tuesday to be day "3" of the week (the name for "Tuesday" is frequently number based on the Days of the week chart http://wiki.riteme.site/wiki/Days_of_the_week#Numerical ) matching the Gregorian calendar. Furthermore, several of the languages on the chart ( http://wiki.riteme.site/wiki/Days_of_the_week#Numerical ) that have Tuesday as day "2" also have a middle of the week name for Wednesday (German has a middle of the week name for Wednesday but no numeric names). If Wednesday is the Middle of the week and Tuesday is day "2" would that not imply that Sunday is day "0" and the day which begins the week (which is how I remember the day of the week function working in UNIX systems in the early 80's). I wonder why the ISO calendar committee decided to switch the beginning day of the week away from Sunday, which it was on the closest thing to an international standard calendar (The Gregorian Calendar) there ever was. Do not get me wrong I think it is important to have a standards based calendar instead of generally accepted religious one. I also think we could use some real calendar reform like the calendars http://wiki.riteme.site/wiki/World_Calendar or http://wiki.riteme.site/wiki/International_Fixed_Calendar both of which have Sunday as the first day of the week. --Boris —Preceding unsigned comment added by Boris58 (talk • contribs) 02:12, 5 September 2007 (UTC)

Sorry about my comment here before reading the start of week stuff at the end. Boris58 14:55, 5 September 2007 (UTC) 14:55, 5 September 2007 (UTC)

-- Hi 131.183.81.100 - I'll think you'll find that the Egyptians started their week on a Saturday. Mintguy

I thought the Egyptian week had ten days. -phma

-- " The US system has weeks from Sunday through Saturday, and partial weeks at the beginning and the end of the year. An advantage is that no separate year numbering like the ISO year is needed, while correspondence of lexicographical order and chronological order is preserved. " There is no US version of ISO 8601. ISO 8601 prescribes Monday as the first day.

ISO 8601 is adopted in the US through ANSI X3.30 and through NIST FIPS 4-1 or whatever revision it is up to now. [anon] 2007-09-05 21:22 UTC

ANSI INCITS 30-1997 (R2003) supersedes ANSI X3.30-1985 (R1991) which is intended for data systems only. The latest revision of FIPS 4 is FIPS PUB 4-2.--Richardrw 2007-09-28 12:38+04

Local time and the difference from UTC

The article seems to imply that ISO times are only appropriate in UTC, but from what I've read, without a time zone designator, times are assumed to be in local time. Putting a Z at the end designates it as UTC, and other time zones can be designated by include a +hh:mm or +hhmm or +hh or -hh:mm or -hhmm or -hh after the time. This is mostly from Markus Kuhn's page. I'll be updating the article accordingly. kmccoy 05:27, 12 Jul 2004 (UTC)

What about using the nautical letter system to designate the time zone? For example, 13:30Z = 14:30A = 12:30N, etc. --  Denelson83  13:31, 6 November 2006 (UTC)

That is not supported by the standard, except for Z. To indicate local time zones, you must specify a time offset. To quote:

4.2.5.1 Difference between local time and UTC of day

When it is required to indicate the difference between local time and UTC of day, the representation of the difference can be expressed in hours and minutes, or hours only. It shall be expressed as positive (i.e. with the leading plus sign [+]) if the local time is ahead of or equal to UTC of day and as negative (i.e. with the leading minus sign [-]) if it is behind UTC of day. The minutes time element of the difference may only be omitted if the difference between the time scales is exactly an integral number of hours.

--Nike 02:55, 7 November 2006 (UTC)

scripting error

There was a script in this article generating the current date/time like

The current time is 2024-11-20T17:38Z
(ISO 8601 format.)

This is sometimes incorrect since it does not use leading zeroes for single digit months or days. In an article like this no example is better than a wrong one. So I removed it.

For example,

 "The current time is 2004-3-2T12:34Z"

should be

 "The current time is 2004-03-02T12:34Z"

If someone can figure out a correct script that would be welcome.

--anon

You forgot to sign. Anyhow, I found the solution because I was annoyed that my (and everyone else's) talk signature was not ISO8601. The trick is {{Twodigit {{CURRENTDAY}}}}, or its template {{CURRENTDAY2}}. That is, the current time in ISO8601 format is 2024–11–20T17:38Z.

I had to use the Twodigit version because I had to prefix subst: to both {{Twodigit}} and {{CURRENTDAY}} to make the signature work. —Daelin @ 2006–01–07 05:20Z

I believe the 'current' time displayed is wrong. I'm running on GMT at the moment (it being winter) and it seems to be out by about an hour. I thought UTC was roughly the same as GMT? Skittle 20:23, 23 February 2006 (UTC)

Mysterious: it is ok for me. I'm in zone +1 and it shows one hour behind as it should. −Woodstone 20:31, 23 February 2006 (UTC)

I'm on GMT and it's out by an hour and ten minutes - very confusing! -Saluton

Are you sure your PC is actually set to time zone 0, and that you are not on daylight saving time. −Woodstone 13:48, 16 March 2006 (UTC)?

Everything bold

Why is everything bold? It makes it easier to pick out the ISO 8601 dates, but I think it makes it harder to read the rest of it. 68.81.231.127 21:40, 16 Dec 2004 (UTC)

ISO 8601:2004

Apparently, ISO 8601:2000 has been superseded by ISO 8601:2004 about two weeks ago. I don't have a copy of the new standard, so I simply hope that none of what is currently in the article has been invalidated by the new revision of the standard. If someone has a copy of the current revision and would like to double-check, or even to note the changes from the 2000 revision to the 2004 one, that would be excellent. -- pne 05:42, 19 Dec 2004 (UTC)

Year 10000 and the expanded representation

Apparently, ISO 8601:2000 stated

“4.7 Expansion

By mutual agreement of the partners in information interchange it is permitted to expand the component identifying the calendar year (...) before the start of the year [0000] or after the end of the year [9999].

When expanded representations are used, provisions should be made to prevent confusion of the expanded representations, with other date and time representations used by the application.”

This last paragraph seems deleted in ISO 8601:2004. I will delete the reference to it in the article as well. I never really understood that paragraph. Even ISO 8601:2000 (section 5.2.1.4 Expanded representations) already required a trailing sign + or - for years outside the range 0000–9999. So there was already a provision to differentiate June 2006 (200406) with the year +200406. (Offsets of local time to UTC do not usually have six figures, as they are normally a integer number of minutes.)

– Adhemar 19:19, 27 July 2007 (UTC)

Do you mean "leading" instead of "trailing"? — Omegatron 04:45, 9 January 2008 (UTC)

Problem with 24:00

I believe, and I put it to anyone, that there is no such thing as a 24:00. Go on and have a look at http://www.npl.co.uk/time/leap_second.html, which informs of the addition of a leap second for 2005-12-31. Notice that it lists precisely where the leap second should be added. Did you also notice that there’s no 24:00 hrs? Why then do people refer to it (see December 31#Holidays and observances)? Why is it mentioned in the ISO8601 standard? In my opinion the end of a day is 23:59:59 hrs, the beginning of a new 00:00:00 hrs (perhaps this should be designated as mid night). There were even headlines which state that the year 2006 was a second late (see: http://www.deccanherald.com/deccanherald/dec252005/national16334620051224.asp). So, why do we use it? Demerzel 15:44, 3 January 2006 (UTC)

There is no 24:00:00 in that example as distinct from 00:00:00 (on the next day). These times refer to the same instant viewed from different dates. Even though there is a leap second at 2005-12-31 23:59:60, this is followed by midnight 2005-12-31 24:00:00 which is equal to 2006-01-01 00:00:00. For more information about the usage and reality of 24:00 see 24-hour clock. −Woodstone 21:47, 3 January 2006 (UTC)

Week 53

A similar convention holds for the week notation of dates. —Daelin @ 2006–01–07 05:22Z

To expand, there is never such a thing as the 7th day of the 53rd week of the year, except that the notation IS a valid ISO 8601 reference to the same day in the next year. Mathematically, the year is at maximum two days longer than 52 weeks, and the first week has a minimum of four days, which means the 53rd week can have a maximum of 5 days within the 366 days of a leap year. However, all days of the week are valid in the 53rd week. At the maximum the fallover days are the first days of the next year which fall before the first week of the new year. Here's the point: When n fewer than five days occur in the 53rd week, those n days refer to the same day as the nth day in the first week of the new year. You would generally not use those week dates in a calendar, but they are valid references from the previous year. Similarly, you would not generally see 24:00:00 on a clock, but it is a valid reference.

In fact, it would be completely valid for a clock to count cardinally from 01 to 60 before rolling over minutes or seconds, instead of ordinally from 00 to 59. This bucks the couple-thousand year old Babylonian convention we draw our clocks from, but it's quite alright. Before people got over their fear of zero as anything but a placeholder, a few clocks did exactly this for minutes. —Daelin @ 2006–01–08 16:14Z

The last days of week 53 are not in the first week (week 1) of the next year. Week 1 follows week 53 (if there is one) without overlap. Your statements above are somewhat ambiguous about that.

The class "wikitable" works only for tables; now it was changed to messagebox and infobox it could work with a "div".

−Woodstone 20:07, 8 January 2006 (UTC)

I thought I clearly stated that. I can't find the ambiguity you're describing. Let me give you an example, however. When January 1st is a Monday, YYYY-01-01 is also YYYY-W01-1. If it's not a leap year, 365 days later it's YYYY-W53-1, a Monday. The next six days of that week fall in the next year, and they are the first week of that year. YYYZ-W01-1 is also YYYY-W53-02, and the remaining days of the 53rd week are all (properly) addresses from the next year. ISO 8601 is very clear that the first week of a year is the first week with a majority of days (Thursday or earlier) in that year. The first week of YYYZ would not begin on YYYZ-01-07, at it appears you're saying, by stating "Week 1 follows week 53 ... without overlap." —Daelin @ 2006–01–08 23:24Z

That's not the way it works. The standard says:

• a week is a contiguous period of seven days, starting on Monday
• week one is the week containing the first Thursday of the year

So let's assume that in the year CC01, CC01-01-01 is on a Thursday. Then:

• week CC01-W01 runs from CC00-12-29 till CC01-01-4

In the year CC02 (if CC01 is not a leap year) date CC01-01-01 will be on a Friday. So the first Thursday in CC02 will be on CC02-01-07, or, by definition CC02-W01-4. So:

• week CC02-W01 runs from CC02-01-04 till CC02-01-10.

Calculating back, this shows that an extra week needs to be inserted:

• week CC01-W53 runs from CC01-12-28 till CC02-01-03

So in a particular year there is either a week 53 or not. There is no overlap between week 53 and week 1 and no ambiguity in naming dates in the week format.

Note that the weeknumbers generated by Microsoft Excel (function WEEKNUM) do not conform to the standard. You can try it out on 2004 (except that it's a leap year). (Why am I not surprised?) −Woodstone

Common year starting on Monday

Common year starting on Thursday

As always, a picture is worth a thousand words. We're talking about different dominical years. There naturally isn't any overlap in the year you're talking about, the first day of the following year is a Friday. I made the following images to illustrate. You'll find the Common year starting on Thursday (D) exactly matches your description, while the Common year starting on Monday (G) matches mine. (They both, of course, match the calendars of the articles linked.) Common years starting on Friday, Saturday, or Sunday, do not have a 53rd week.

There is no ambiguity with having two possible dates associated with one day, just as there is no ambiguity with having two possible times associated with the same moment (00:00 and 24:00). Convention (and convenience in programming) dictates that we use the notation of the higher significant value (00:00 of the next day, W01 of the next year).

So, here's the point of debate, illustrated in [[Image:Dominical_Year_G.png]]. The year you described doesn't illustrate this. You said:

That's not the way it works. The standard says:
* a week is a contiguous period of seven days, starting on Monday 
* week one is the week containing the first Thursday of the year

You did not say a week of a given year must have Thursday fall within that year. I don't think this is implied. December 31st in a G year falls in the 53rd week. Now, you might want to call this FFFF-W01-01 (FFFF-W01-02 being the first day of the new year), but it seems completely valid to refer to this as GGGG-W53-01. Generally, I expect you wouldn't, just as you wouldn't refer to 24:00 except for occational convenience. —Daelin @ 2006–01–10 11:43Z

I think you are definitely wrong. The length of the year is about 365.25 days, so 1.25 days longer than 52 weeks. As a consequence about every 7/1.25=5.6 years a week 53 needs to be inserted. This happens in a slightly irregular pattern caused by the leap years. In other years there is no week 53. Your picture of year G is plain wrong. −Woodstone 14:02, 10 January 2006 (UTC)

It's incorrect to use decimal math in this discussion. By describing the year as you just have, you're assuming the year always has seven days in the first week. This is explicitly not the case, by defining the first week as the first one with Thursday. Further, the calendar year does not consider the extra half-day. The leap years are there to increase regularity. This is a matter of discrete mathematics. What, exactly, is wrong with my graphic of dominical year G?

Consider a Common year starting on Wednesday. That is, EEEE-01-01 = EEEE-W01-03. The year is (52×7)+1 days long, so one day falls after week 52, when starting on Monday. Starting on Wednesday, the days are shifted by two (Monday and Tuesday), so that there are now three days that fall after the 52nd week. Do you disagree with this part of the proof? —Daelin @ 2006–01–11 11:03Z

First of all what's wrong in your picture is that you show Dec 31 in year G to be in week 53. However in this case there is no week 53. So that Monday is (only) in week 1 of the next year.

Using the decimal value is ok on average. Most years have exactly 52 weeks (in the ISO standard), although some days may spill into or be borrowed from bordering years. However because of the accumulation of the 365th day and the occasional leap days, a shortage builds up, so a whole week, numbered 53 has to be inserted after the threshold (determined by first Thursday) is reached.

ISO does its utmost to keep their standards secret, by charging outrageous amounts for a copy, but a rather authoritative explanation can be found at: International standard date and time notation. It has a section explaining explicitly the facts around week 53. Please have a look. −Woodstone 12:54, 11 January 2006 (UTC)

Read this excelent explanation The Mathematics of the ISO 8601 Calendar – The ISO 8601 calendar. I've also added a parameter request at Metawiki so it's possible to use the ISO week notation. See Request #time-parameter o - ISO-8601 year number so it should be poosible to use this: 2024-W47-3. A comment and a proposed UDF for Excel can be found here Excel treats weeks in a strange way. Nsaa 08:01, 24 October 2006 (UTC)

I've added three Templates (based on templates from MediaWiki):

* [[Template:ISOYEAR]] – {{evd|ISOYEAR|2004|12|31}}, today: {{evd|ISOYEAR|{{CURRENTYEAR}}|{{CURRENTMONTH}}|{{CURRENTDAY}}}}
* [[Template:ISOWEEK]] – {{evd|ISOWEEK|2004|12|31}}, today: {{evd|ISOWEEK|{{CURRENTYEAR}}|{{CURRENTMONTH}}|{{CURRENTDAY}}}}
* [[Template:ISOWEEKDAY]] – {{evd|ISOWEEKDAY|2004|12|31}}, today: {{evd|ISOWEEKDAY|{{CURRENTYEAR}}|{{CURRENTMONTH}}|{{CURRENTDAY}}}}
* [[Template:ISOWEEKDATE]] – {{evd|ISOWEEKDATE|2004|12|31}}, today: {{evd|ISOWEEKDATE}}

Examples where the ISO year is three days into the next gregorian year:
*{{evd|ISOWEEKDATE|2009|12|31}}
*{{evd|ISOWEEKDATE|2010|1|1}}
*{{evd|ISOWEEKDATE|2010|1|2}}
*'''{{evd|ISOWEEKDATE|2010|1|3}}'''
*{{evd|ISOWEEKDATE|2010|1|4}}

Examples where the ISO year is three days into the previous gregorian year:
*{{evd|ISOWEEKDATE|2008|12|28}}
*'''{{evd|ISOWEEKDATE|2008|12|29}}'''
*{{evd|ISOWEEKDATE|2008|12|30}}
*{{evd|ISOWEEKDATE|2008|12|31}}
*{{evd|ISOWEEKDATE|2009|1|1}}

Nsaa 12:26, 14 November 2006 (UTC)

Systematic use of bolding

The text is fairly dense. I used bolding to make each major point skimmable. I felt it improved readability. In my opinion, using bold for the numerical values adds noise. I don't particularly like the quotes, but I think they're less "loud" and keep the text from looking like chocolate chip icecream. It could do without quotes entirely, considering how numbers are inherently typeset differently. It's just not as obvious in the monobook theme's font. I would like to return to the previous bolding, unless there's a stylistic complaint. —Daelin @ 2006–01–07 15:31Z

Before my preceding edit, there was a lot of bold and bold Italic, making the article look like a screaming flyer of a cheap shop. The WP style manual discourages bolding. I tried to reduce by using as a rule:

• definitions and examples of the norm: bold
• key concepts: italic.
• non-standard date/time: in "quotes"

It's become much quieter, but I agree it now looks like a chocolate chip cookie. We could experiment with using quotes instead of bolding (for examples only, or both defintions and examples).

I like the idea of the small boxes on the right, but the current "tt" letter is just ugly, can we go back to default fonts? −Woodstone 17:04, 7 January 2006 (UTC)

Yeah. I made the change to emphasize when spaces are used, since variable width fonts obscur that. This is especially evident with the <date>T<time> and <date> <time>, where the space is hardly visible. I'm not sure the ugly is worth it. If we used font-family (Bitstream Vera Sans Mono is beautiful), we'd really want a template. —Daelin @ 2006–01–07 17:11Z

Displaying a century

Can you really display a century as just 19? This should be ambiguous with the century-shortened YY form. I can't see the century form being at all useful, as language is required to explain it in any context. Further, it's part of a unit. While YY also is, there's no trade convention (or use) for the century. Does anyone have a copy of the standard? I'm nixing it for now: safe move, not useful information. —Daelin @ 2006–01–07 16:28Z

Yes, section 5.2.1.2(c) specifies that a specific century may be written with just two digits. If you're intending a year, you would write it as -YY, to show that it's in the "implied" century, per 5.2.1.3(c), unless there's no other way to interpret it. 5.2.1.3(a) shows "a specific date in the implied century" as YYMMDD, but "a specific year and month in the implied century" is -YYMM. kmccoy (talk) 03:14, 9 January 2006 (UTC)

Isn't there ambiguity between -YY implying a century, and -YY being a negative (BCE) century? --Jibjibjib 06:22, 27 March 2006 (UTC)

There was. However, ISO 8601:2004 version eliminates the option to omit the implied century in representing a year (introduced in the version of 2000) and requires again at least a four-digit year. – Adhemar 08:41, 28 July 2007 (UTC)

Astronomers' convention

I always find ISO 8601 dates hard to read (because they are just a string of numbers). What I find is more useful is the system used by astronomers: YYYY Month D"d" H"h" M"m" S"s" Timezone (e.g. now is 2006 March 28d 20h 52m 29s UTC+1h). A quicker way to write this is 2006/3/28;19:52'29"A (note the different symbols for each level as opposed to just colons and dashes as outlined by the standard). I just included this as a comparison. Gee Eight 2006 March 28d 19h 56m UTC

One of the stated advantages of the ISO format is that it doesn't depend on a language's month names. — Omegatron 04:47, 9 January 2008 (UTC)

Space as time designator

The articles states:

...another separator may be chosen with discretion. A space is a popular allowed human readable alternative.

...The standard allows the replacement of T with a space or underscore if no misunderstanding arises. This is commonly done for human communications. A date/time with timezone like 1981-04-05T14:30-05 would then be written as 1981-04-05 14:30-05.

I don't have a copy of the 2004 edition, but in ISO 8601:2000 section 4.4 it states:

The space character shall not be used in the representations.

Section 5.4.1 states:

The character [T] shall be used as time designator to indicate the start of the representation of time of the day in date and time expressions...

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 combined date and time of the day representation with others defined in this International Standard.

I asked in the ISO8601 mailing list if this had been changed in 2004 and was told that it has not, so I would like to know where and what is said in 2004 that allows any character other than T to be used as time designator, so that those who believe otherwise can be corrected, or else the article should be corrected. (Note that omitting the character is not the same as replacing it with a space.) --Nike 10:54, 10 July 2006 (UTC)

Technically omitting the T is not the same as replacing it with space, but you must admit that it is extremely unlikely that the standard intends to allow the form 1981-04-0514:30-05. It is commonly interpreted to allow 1981-04-05 14:30-05. I have never seen an underscore mentioned elsewhere or seen used as a time designator. −Woodstone 13:11, 10 July 2006 (UTC)

I don't know who is "commonly interpreting" the standard this way. I also don't know why anyone would interpret it to mean the opposite of what it says. Yes, it would be easier for humans to read that way, and I often represent the date and time that way, myself, when I am not worried about compliance. But the standard is intended for data interchange between data processing systems, where a space has a special meaning. A computer would have no problem correctly understanding 1981-04-0514:30-05, but, more to the point, it is completely unnecessary to use this format. When it makes most sense to omit the time designator is when using the basic format, e.g. 19810405T143005. The time designator may be omitted if an all-numeric representation is required: 19810405143005. For human readability, extended format may be used, with designator: 1981-04-05T14:30-05.

ISO 8601:2004 section 3.4.1 states:

Unless explicitly allowed by this International Standard the character "space" shall not be used in the representations.

Future editions may allow it, but there is nothing in the current standard that explicitly allows a space to be used. If no space is allowed, then no space is allowed. Nowhere is there even an example of this use in the actual standard document, and yet for some reason this article has several, and represents that this is part of the standard. The encylcopedia article should reflect the actual standard, not what some might want or interpret it to be. --Nike 05:37, 11 July 2006 (UTC)

If you read carefully, you will see that the standard talks about "date representations" and "time representations", and only about "combined date and time expressions". So the statement "The space character shall not be used in the representations." does not apply to the time designator, which comes between two representations. So in human text applications, the date and time representations can be considered to be in two separate fields, separated by whatever is used as separater in such context (i.e. a space). −Woodstone 08:27, 11 July 2006 (UTC)

This is true, if the date and time are two separate fields. However, this is not what the article stated. The article is about the standard, and the standard does not state this. However, I do not object if such a statement is included in the article, so long as the standard is complied with in the rest of the article. --Nike

I just checked the 2004 draft standard, and it seems to use "representation" and "expression" interchangably. The section titled Date and time of the day starts with:

When the application does not clearly identify the need for only a date expression (see 5.1) or only a time of the day expression (see 5.2), then a time-point can be identified through a date and time of the day representation. [emphasis added]

Note that the language here is exactly the opposite of what is stated by Woodstone. The follows the subsection titled Complete representation, which which states:

The time elements of a date and time of the day expression shall be written in the following sequence

a) For calendar dates:

year - month - day - time designator - hour - minute - second - zone designator

...

The character [T] shall be used as time designator to indicate the start of the representation of the time of the day component in these expressions... [emphasis added]

The following are examples of complete representations of date and time of the day representations:

Basic format: YYYYMMDDThhmmss Example: 19850412T101530

...

Extended format: YYYY-MM-DDThh:mm:ss Example: 1985-04-12T10:15:30

--Nike 11:08, 12 July 2006 (UTC)

I am with Woodstone here, <foo date="1985-04-12" time="10:15:30"/> was okay as was <foo datetime="1985-04-12T10:15:30"/>, but <foo datetime="1985-04-12 10:15:30"/> (with a space instead of a T) was not compliant. The current text in ISO 8601#Combined representations supports this view. Christoph Päper 23:24, 28 February 2007 (UTC)

I think the designers of the standard made a bad decision choosing T, a letter, as a separator. It would be much more sensible to use a symbol which is much more commonly interpreted as a separator. The SPACE would be great for human readability, but it could lead to interpreting two separate data items (as I think they argue).

Symbols such as '_', '|', '.', '!', '/' (oh, this one is for intervals...) for example would have been ideal for a balance between machine readability and human readability (I propose '_' as the closest to a space without being a space, or maybe '|').

In "2007-02-23T12:40:30" I would quickly see 5 tokens, the third of which would be "23T12", and not the intended two parts, with three elements each.

--Asegura 19:08, 28 February 2007 (UTC)

This is not the place to propose something like this, but it might be noted in ISO 8601#Proprietary extension, if someone implements (optional) support for _ instead of T in an otherwise compliant implementation. The variant with two fields is explained in the relevant section. The period would not work because of fractional datetimes, by the way. Christoph Päper 23:24, 28 February 2007 (UTC)

OK, that's true, this is for discussing the correctness of the article. I (we) can remove the whole comment if you think it's appropriate. --Asegura 11:42, 2 March 2007 (UTC)

ISO has always allowed 2001-02-03T04:05:06 and 2001-02-03 and 04:05:06 ; they are date/time and date and time. So 2001-02-03 04:05:06 has always been allowed. It does not represent a date/time, but a date and a time which will presumably be in the same day. There is no practical difference. 82.163.24.100 (talk) 21:59, 24 September 2008 (UTC)

Example Date Incorrect?

Current date and time in UTC 2006-08-18T19:18Z

My clock currently says 21:18, and I live in London, England. We're currently in the BST timezone, which is GMT+1, which means that the date being shown is incorrect as UTC is the same as GMT, is it not? --Veratien 20:22, 18 August 2006 (UTC)

We're repeatedly told that template times are not accurate due to caching, so I'm guessing that's what happened to you. It shows me "2006-08-19T02:28Z", which is only a few minutes off. --Nike 02:32, 19 August 2006 (UTC)

Since I'd never visited the page before, and it was exactly an hour slow, I doubt this is the reason. ;) 'Twas definitely wrong --Veratien 01:22, 21 August 2006 (UTC)

The caching occurs server-side, not in the browser. You do not have to visit before for it to be cached. At least, that's what they keep telling us, why we should not use templates to attempt show the current time. Is it still slow? --Nike 06:25, 22 August 2006 (UTC)

Yeah, it's showing 13:00 at the moment. Perhaps "Example date time in UTC" would be better, since it rarely seems to be current? --Veratien 13:41, 22 August 2006 (UTC)

It always seems pretty accurate for me, but it may depend on how close to the server you are. It used to say "(when page was sent)" which was removed a couple of weeks ago with the comment "wikipedia's web accelerators cache this so it ain't really true", then the next day someone added the word "Current". I would support your suggestion. --Nike 11:56, 23 August 2006 (UTC)

Then it is done. --Veratien 23:49, 23 August 2006 (UTC)

Use of angular brackets

The text of the standard does not use angular brackets (like <YYYY>) enclosing the notation elements. Therefore this article should not do that either. Unless there are very pressing reasons given here, I will revert soon. −Woodstone 09:45, 10 September 2006 (UTC)

I double checked, and noted that the standard uses bare symbols (like YYYY) in bullets, examples and tables, but square brackets like [YYYY] in running text. −Woodstone 18:27, 10 September 2006 (UTC)

Day of the Week

Is there a way of indicating the day of the week in English along with the ISO 8601 standard, e.g. 2006-10-16 (Monday). I understand that the ISO standard is supposed to remove language barriers and by adding the English names for the day of the week is essentially re-introducing incompatibility between languages. However, in everyday life, I find it convenient to know what day of the week the date is in reference to. For example, common practice for the long date style in the US is to write the day of the week first followed by a comma, a space, and then the date, i.e. Monday, October 16, 2006. In Chinese and Japanese, the standard format is to enclose the day of the week in parentheses and append it to the date, i.e. 2006-10-16 (星期一) or 2006-10-16 (月), respectively. Enclosure in parentheses make sense because the day of the week is a nice-to-know, trivial piece of information.

Will this format of writing the day of the week make sense in English too? 2006-10-16 (Monday). Or perhaps, for the long date format, 2006 October 16, Monday. Here are the suggestions used in a sentence:

1. Please attend our technical session on 2006-10-16 (Monday) at 12:30.

2. Our technical session will be held on 2006 October 16, Monday, at 12:30.

The first example is basically the ISO 8601 with the day of the week thrown in. The second example is long date format written in ISO 8601 style with the day of the week thrown in.

When considering the time too, I have no idea which position is the most logical to place the day of the week.

Constructive criticism is greatly appreciated.

Silver Handprint 15:10, 16 October 2006

I personally always use the style "Monday 2006-10-16 12:30". This preserves the date/time as in ISO (with T omitted for human readable text). The standard only uses day numbers (Monday=1) in combination with week numbers: "2006-W42-1". −Woodstone 19:31, 16 October 2006 (UTC)

The day of week is not supported as part of the standard for ISO calendar dates. However, additional non-ISO information may be included in separate fields, outside of the ISO field(s). Alternatively, the ISO week date can be included alongside the calendar date as a separate ISO field, e.g. 2006-W42-1 2006-10-16T12:30. (An record such as "2006-10-16 12:30" would also represent two separate ISO fields.)

Previous editions of the standard permitted a truncated representation of the day of week, with implied year and week number, e.g. -W-1 (Monday). The current edition does not support this, however. It's actually redundant, since each ISO calendar date is associated with exactly one day of the week, which can be determined from a calendar or date software. --Nike 01:46, 17 October 2006 (UTC)

Proprietary extensions

There are no quarters defined in ISO 8601:2004(E), nor are they mentioned anywhere in the document. I recommend removing the section from the article. MadIce 22:04, 4 November 2006 (UTC)

Quarters is part of the Proprietary extensions section, which means that they are not part of the standard, by definition. However, no sources are provided for any of the so-called Proprietary extensions, nor any information even as to who the proprietors might be. --Nike 01:34, 5 November 2006 (UTC)

I have seen 'Q'Q-DD notation in commercial practice, but I do not remember where it was (nor what definition of quarter they were using)—it may have been on Bloomberg TV Germany, where YYYY'Q'Q is common at least. IMVHO the ISO should define quarters unambiguously.

There are several programming languages that are documented as accepting 0 as an alternative (or even preferred) value (besides 7) for Sunday, IIRC one was the Basic variant of IBM’s Lotus Office Suite and another Dot Net in a certain mode. The rest may be original research, but IMO should be kept nevertheless.

BTW, is there an accepted notation compatible to ISO 8601 for a recurring / scheduled event of a certain length (e.g. a 45-min TV show on 13 Wednesdays at 21:00Z from the first week of September)? Christoph Päper 14:32, 12 November 2006 (UTC)

The standard allows intervals which can be specified by a start and an end; by a duration and context information; by a start and a duration; and by a duration and an end. It also allows one to specify recurring time intervals in a similar fashion. So, I think the answer would be "yes". ;) MadIce 19:08, 13 November 2006 (UTC)

So thought i, but i was not able to encode the Example (or actually something very similar), but after thinking about it again, i came up with: R13/-W36-3T21Z/PT45M. (I only guessed the Weeknumber, because -09-W1 is not legal). Now i only need some (external or porprietary) Mechanism to specify Exceptions, like …\R2/-W52 for a Christmas-Break. Christoph Päper 11:36, 14 November 2006 (UTC)

YYYYMM format

I'm very tempted to make a correction in this article.

The article states that a month can be specified either as YYYYMM or YYYY-MM. However, section 4.1.2.3 and 4.1.2.4 of ISO 8601:2004 clearly state that the YYYY-MM format is the only legal one. YYYYMM should therefore be removed from the article.

The only reason I hesitate to do it myself is because I don't understand why YYYYMM is illegal. The standard allows us to choose between YYYYMMDD and YYYY-MM-DD, or between YYYYDDD and YYYY-DDD (where DDD is the ordinal day number within the year). Why, then, is YYYYMM forbidden?

--Oz1cz 15:28, 21 January 2007 (UTC)

I had never noticed it before, but upon double checking it appears that you are correct in stating that the standard disallows that format. I suspect the reason is to avoid confusion with the many interpretations in current use of 6-digit dates. A form like 200701 could be misinterpreted as 2001-07-20. For 2007-01 this would not happen. −Woodstone 15:56, 21 January 2007 (UTC)

Or perhaps it is a rule left over from older versions of the standard. In previous versions of the standard, the century could be omitted from the year. So 2007-02-06 could be written as 07-02-06, or simply 070206. If YYYYMM had been legal, 070206 could mean both "6 February xx07" or "June 702". When they outlawed the YYMMDD format, perhaps the standard writers forgot (or deliberatly refrained from) permitting YYYYMM, even though that was no longer ambiguous. (I'm only guessing.)--Oz1cz 07:41, 6 February 2007 (UTC)

YYYYYY is allowed by ISO 8601, but I believe it has to be written as +YYYYYY now.

To 129.247.31.124: After your revision to the last sentence of the "Year" section, it now reads, "By disallowing dates of the form YYYYMM, the standard avoids confusion with the truncated format YYMMDD (still often used)." I suggest revising the wording within the brackets to read, "(still often used, but contrary to the standard)" to clearly distinguish the fact that YYMMDD representations are not allowed by the Standard. What do you think?--Richardrw 2007-11-23 22:56+04

Proprietary extensions - Week_of_month

The section ISO_8601#Week_of_month states "months can also unambiguously be divided into four or five weeks". This should be four, five or six weeks?

• The month 2010-02 spans only four weeks (2010-W05-1/2010-W08-7)
• The month 2010-03 spans five weeks (2010-W09-1/2010-W13-3)
• The month 2010-08 spans six weeks (2010-W30-7/2010-W35-2)

Nsaa 11:57, 22 January 2007 (UTC)

Those extensions (would) use the definition also used for first and last week of a year. Accordingly a week is only in a month if they share at least four days. Each month has at least four weeks. In conclusion a six-week month would have to have at least 4×7 + 2×4 = 36 days. No Gregorian month has more than 31 days, so there is none with six (ISO) weeks. Note that as a consequence of this proprietary notation a (ISO week) month had exactly four or exactly five weeks, i.e. 28 or 35 days; compare to the (ISO week) year that has exactly 52 or exactly 53 weeks (364 or 371 days). Christoph Päper 14:23, 23 January 2007 (UTC)

ISO 8601:2006

The german article states that the latest release of this standard was published in 2006-09. Please check this and update if appropriate. -- Fleasoft 10:40, 31 January 2007 (UTC)

Nowhere does it say "ISO 8601:2006". In fact, it specifically refers to ISO 8601:2004. The date they're talking about is for the release of the German (DIN) version. "Im September 2006 löst die neue DIN ISO 8601 diese Normen ab." Besides, you should raise the issue over there, not on the English version. --Nike 11:44, 31 January 2007 (UTC)

"Possible source of confusion"

A possible source of confusion in doing time zone conversions is the ISO committee's decision to create time expressions using offsets from UTC rather than to UTC (i.e., having opposite sign).

I'm not sure this makes sense. Opposite sign to what? UTC-5 would have the time represented as [hh]:[mm]:[ss]-5, right?

--Awesome 06:43, 7 February 2007 (UTC)

I think the point is this: If you write UTC-5, this indicates that you should subtract 5 hours from UTC to get local time. This is all fine and natural. But if you write hh:mm:ss-5 the "hh:mm:ss" is given in local time, so the expression seems to indicate that you are supposed to subtract 5 hours from local time, which is clearly not the intention.--Oz1cz 07:39, 7 February 2007 (UTC)

No it means that you are in a place that *has* subtracted 5 hours from UTC to arrive at the local time zone. The + and - for time zones follows the same sign convention as for the + and - for measuring degrees longitude around the globe: + is East and - is West. —Preceding unsigned comment added by 81.178.220.140 (talk) 21:22, 5 September 2007 (UTC)

I agree, this section introduces more confusion than it clarifies. The article clearly states how the standard specifies time zones in a previous section. The confusion is introduced by calling the time an "expression", it is not, it's a label. This section smacks of OR, if not can we have a citation to evidence of it being confusing? The committee's decision follows the convention used by other standards, there is nothing perverse about it.

The confusion aspect is just a red herring. And we don't really need a section explaining how to do simple math do we? I suggest this section is deleted.

--Bobcousins 14:28, 2 November 2007 (UTC)

I also agree with the above comments. This section is confusing and could be simplified. The issue about the offset either being “from” or “to” UTC is moot. The standard is written “from” UTC. In addition, most maps of time zones that I have seen show time zones east of Greenwich as positive and those west as negative. However, I think the time conversion equations should be preserved, but revised. Although the math is simple, the concept of converting time between time zones using the UTC offset or zone designator is not. I have deleted the first paragraph and revised the time zone conversion equations. I have added the term “zone designator” throughout Section 4.1 as this is the term used in the standard.--Richardrw 2007-11-09 20:33+04

Various observations on Main Page and Talk

Main Page

History

The section has a link for ISO 8601:2004, apparently to ISO, offering PDF price CHF 126.

http://www.merlyn.demon.co.uk/datefmts.htm has a link to download ISO 8601:2004 PDF, apparently from ISO, price nil.

Does giving the former link have any advantages? 82.163.24.100 (talk) 22:15, 30 September 2008 (UTC)

The first paragraph ends with "It has since then been superseded by a second edition in 2000 and finally the current third edition, ISO 8601:2004, published 2004-12-03.". Is there any justification for the "finally"? The following will be better : "It has been superseded by the second edition in 2000 and the current third edition, ISO 8601:2004, published 2004-12-03.". 82.163.24.100 (talk) 21:35, 4 October 2008 (UTC)

I do not see any signifcant detraction in the meaning of the sentence with the removal of the word "finally." 12.163.55.2 (talk) 18:05, 5 October 2008 (UTC)

Years

Has "citation needed" - well, http://www/merlyn.demon.co.uk/upg-8601.txt says so, but there must be better references to cite. It's an obvious fault, and a remedy is suggested there. It is, of course, necessary to define a particular day, not just a year.

Then add it to the article. --Nike 07:29, 10 February 2007 (UTC)

It should only be added if enough better references are not available; that is not yet established. Since that page refers to updating 8601:2000, it is in need of a rewrite anyway.

I'm not going to edit articles themselves without further practice and a more solid knowledge of the system.

82.163.24.100 18:29, 10 February 2007 (UTC)

The update, referring to 8601:2004(E), is now at http://www/merlyn.demon.co.uk/u-8601-3.txt . 82.163.24.100 (talk) 19:32, 26 September 2008 (UTC)

Week Dates

There is only one definition of Week 1; it contains the First Thursday - ISO 8601:2000 4.3.2.2. (check in :2004). The others are at most mere equivalences.

Why refer to the outdated edition, when the 2004 edition is freely available on the Internet? Why not check it yourself?

Because I was not aware that it is now available. I doubt whether it has been available for long; apparently you yourself did not have it 7 months ago (see above).

82.163.24.100 18:29, 10 February 2007 (UTC)

2.2.10 states:

"calendar week number

"ordinal number which identifies a calendar week within its calendar year according to the rule that the first calendar week of a year is that one which includes the first Thursday of that year and that the last calendar week of a calendar year is the week immediately preceding the first calendar week of the next calendar year"

In 3.2.2 The week calendar it states:

"NOTE 2 The first calendar week of a calendar year includes up to three days from the previous calendar year; the last calendar week of a calendar year includes up to three days from the following calendar year. Therefore, for certain calendar days the calendar date contains a different calendar year than the week date..."

"NOTE 3 The rule for determining the first calendar week (see the definition of calendar week number in Clause 2) is equivalent with the rule “the first calendar week is the calendar week which includes 4 January”."

However, it seems to me that all the definitions given are true. --Nike 07:29, 10 February 2007 (UTC)

There is only one definition, in 2.2.10. The other statements are equivalent and true, but are not the definition. The main page should describe "First Thursday" as the ISO definition, and the others as merely equivalent.

82.163.24.100 18:29, 10 February 2007 (UTC)

There is a Microsoft VBScript routine, DatePart, which might be thought with suitable parameters to give the ISO Week Number. It does so for all but 3 days per 28 years (in Win98 IE4 & WinXP IE6 IE7; Vista unknown). http://www.merlyn.demon.co.uk/vb-date2.htm#WN refers and tests and has good code. All good ISO WN routines need to return both YYYY & WW, and can easily return D too.

I fail to see the relevance, especially when it does not work. --Nike 07:29, 10 February 2007 (UTC)

For the actual use of ISO week numbering in IT, it is important to have a WN algorithm, and that it be correct. It seems worth knowing that DatePart is not such a routine, even though some (including MS) may think that it is. A routine which is usually correct is more dangerous than one which is obviously wrong. I cited a source of correct code.

82.163.24.100 18:29, 10 February 2007 (UTC)

Talk

Example Date Incorrect?

Surely there is no BST time zone here? Time Zones are geographically fixed (with occasional adjustments). We don't change zones seasonally, but we do change offsets.

You are misreading the comment. Nobody is claiming that BST is part of the standard. The commenter was just stating that he, personally, was in that time zone. --Nike 07:29, 10 February 2007 (UTC)

Of course; and I was stating that he was mis-describing his situation. BST is not a Time Zone.

82.163.24.100 18:29, 10 February 2007 (UTC)

Day of the Week

As it is a standard for numeric dates, independent of language provided that the characters 0123456789 +-/:.TZ are available, the Day-of-Week should NOT be given in English within the date. But 2007-02-09 (5) would be reasonable for today, Friday. The local-language Day-of-Week can be given before or after the date.

The day of week, aside from use of the week calendar, is not supported by the standard, but there is no reason why it cannot be transmitted as a separate field, and there are no rules for non-standard fields. In any event, the article should be about the standard, not what is outside the standard. --Nike 07:29, 10 February 2007 (UTC)

General

It's a long article; how about splitting it into what is seen as indisputably standard, and modifications/additions? 82.163.24.100 23:47, 9 February 2007 (UTC)

The section on Proposed Extensions is pretty short, and separating it from the main article would not significantly shorten it. Nor does the subject warrant a separate article, IMHO. The length of the article does not seem to be excessive, and I do not see the benefit of dividing it. --Nike 07:29, 10 February 2007 (UTC)

There's more that might go into "Extensions"; splitting is still a possibility for the future.

82.163.24.100 18:29, 10 February 2007 (UTC)

By the way, in "Usage", is the "packaging" date certainly ISO 8601, or doee it just look similar? Will products dated for 2008-12-29 actually show 2009-W01?

The body seems to say nothing about sorting ISO ISO dates and/or times; it is a major, but not necessarily obvious, advantage of ISO 8601 that, for matching formats within 1000-9999 at least, a string sort is a date sort.

I suggest a section on "Benefits", including unambiguity (no MDY/DMY (though in the USA YYYYDDMM can be found by Google)), language independence and ease of sorting. 82.163.24.100 18:29, 10 February 2007 (UTC)

Before 0001

There seems to be a "buzz" that 8601 uses year zero - and a resulting interpretation that 8601 involves a transformation for all years before 0001. However, after reviewing the source material, it appears that 8601 recommends how to write the year zero in the proleptic Gregorian calendar (as 0000). It does not say "use the proleptic calendar" nor "use the year zero", nor that "5BC/BCE is to be written as -0004". (Actually, I have seen, so far, no examples at all of how to write -years.) I think what 8601 does say is more akin to "*IF* you are using (the proleptic) year zero, write it this way..." --JimWae 06:49, 3 March 2007 (UTC)

I don't know what "buzz" you mean, but the standard represents the year 1 BCE as 0000 and the year 2 BCE as -0001, etc. 5 BCE is indeed represented as -0004. This is explained, briefly, in the article The letters AD, CE, BC or BCE are NOT used, ever. All years before 1583 are in the proleptic Gregorian calendar, and thus do not correspond to most recorded historical dates before then. Of course, you are not required to refer to this historical period, but if you do, that is how it is written when using the standard. --Nike 20:57, 3 March 2007 (UTC)

There is nothing in the article that says 5BC is to be written as -0004 instead of as -0005. Nor can I find anything in the source material that is freely available on the Internet, that says such. --JimWae 21:08, 3 March 2007 (UTC)

The article plainly says, "Years before the epoch (year zero) are always preceded by a minus sign (-)." Obviously, that applies to all such years, without having to specifically list an infinite number of years. The year before year 0001 is the year 0 (0000), by definition, which in AD/BC notation is the year 1 BC. The years preceding year 0 are preceded by a minus sign, like it says, so the year before year 0 is -0001, which is also 2 BCE, -0002 is 3 BCE, etc. There is no reason to specifically refer to the year -0004, since it is simple mathematics to count backwards from 0. This is described in the standard as an extended representation. As is clearly stated, years outside the range 0000 to 9999 take a sign, and the sign for years less than 0000 is negative. And it would make no sense to represent 5 BC as -0005, because there is no year 0 in AD/BC notation, and thus no negative BC years. The standard does not describe BC notation, because that is not part of the standard. Nor are negative years commonly used with the standard, because it is primarily intended for use of modern dates. There just is not that much need for representing ancient dates, but when the need does arise, the standard does provide for it. --Nike 13:10, 4 March 2007 (UTC)

Although the current standard does not mention AD/BC notation, the previous edition did:

Also note that the year numbers of years before the calendar year [0001] differ from the year numbers in the “BC/AD calendar system”, where the year “1 BC” is followed by the year “1 AD”.

--Nike 13:24, 4 March 2007 (UTC)

Annex B to ISO 8601:2004: "B.1.1 Calendar date —" has the example "-0002-04-12" with the explanation: "Expanded; four digits to represent the year. The twelfth of April in the second year before the year [0000]." where "expanded" means extra characters have been added to represent years beyond the range [0000] to [9999] (2.3.8), and "four digits to represent the year" means that five or six digits are not used—the year must have at least four digits. "In expressions for calendar dates — calendar year is, unless otherwise specified, represented by four digits. Calendar years are numbered in ascending order according to the Gregorian calendar by values in the range [0000] to [9999]. Values in the range [0000] through [1582] shall only be used by mutual agreement of the partners in information exchange." (4.1.2.1) Indeed, any year before 1583, including negative years, can only be used by mutual agreement. But if agreement is reached, then that expanded represention must follow the rules of the standard (3.3). "Consecutive calendar years are identified by sequentially assigned year numbers." (3.2.1) This means the years before [0001] must be sequential, specifically [-0001], [0000], [0001]. A jump from [-0001] to [0001] is not permitted. — Joe Kress 02:35, 7 March 2007 (UTC)

Ooch! There is more on this hoax at User talk:JimWae#Common Era again. Kind regards. — SomeHuman 08 Sep2007 16:08 (UTC) (retracted — SomeHuman 08 Sep2007 17:15 (UTC))

Example useless

The example show for today is 2007-04-12. There is no indication that this is today's date. In fact according to my PC it is the 13th today but I'm in London so I suspect this is a different problem. When both the numbers for the month and day are 12 or lower the reader has no idea which is which. It's ok for use because we know the format of the ISO date but for anyone using the example - they don't know. Maybe the best correction would be to write the date out in words above the example.

Today is 12th April 2007, time is 9:30am. Examples in ISO format shown below. —The preceding unsigned comment was added by 87.84.74.52 (talk) 08:31, 13 April 2007 (UTC).

How would this addition help to clarify 2007-04-04? −Woodstone 11:07, 13 April 2007 (UTC)

I definitely agree the example should be clearly flagged as todays's date — if it is! There appears to be a bug deep in the underlying code, which is perhaps getting the date & time from a server somewhere in the U.S.(?), because in Melbourne it is 2008-05-24, and the example shown is 2008-05-23.

Given this hitch, I also agree that having the date written out in words would be helpful. Even for those of us who might not remember what day it is! ;-) I agree that this doesn't immediately resolve confusion over dates such as 2007-04-04: this could be alleviated by colour-coding the year, month and day.

—DIV (128.250.80.15 (talk) 08:07, 24 May 2008 (UTC))

Fractional seconds

It is stated that any of the components of an ISO 8601 date/time can include decimal fractions. Does this include fractional seconds, e.g, 2007-05-29T20:41:16.375 ? — Loadmaster 20:40, 29 May 2007 (UTC)

It applies only to time, not date. Only hours, minutes or seconds can have a decimal fraction. A fraction can only be used in the last present component. So if fractional minutes are used, no seconds can be there. Your example is correct. −Woodstone 21:08, 29 May 2007 (UTC)

The wording at the moment, which I find ambiguous, reads

• Finally, the standard supports the addition of a decimal fraction to the smallest time unit, where higher precision is needed.

May I suggest the following instead:

• Finally, if the smallest time unit is an hour or less (i.e., hours, minutes or seconds) the standard supports the addition of a decimal fraction to the smallest time unit. If the smallest time unit is a day or greater the decimal fraction is not permitted

The point is that days, months and years are also units of time. Thunderbird2 16:19, 4 October 2007 (UTC)

That is still unclear in some ways. Maybe quote an example: you can have 3.5 hours, or 3 hours and 24.7 minutes, or 3 hours, 24 minutes, and 18.4 seconds. It also uses less words. anon 2007-10-08 16:30 (UTC) —Preceding unsigned comment added by 81.178.113.215 (talk)

Or better still, the same time expressed different ways: 12:24:36 = 12:24.6 = 12.41 h. −Woodstone 17:33, 8 October 2007 (UTC)

interval without slash

http://www.cs.tut.fi/~jkorpela/iso8601.html mentions "..." and this long "-" (can't type it here). The article mentions double hyphen. E.g. 2007-06-26--28 , 2007-06-26--07-01 , 15:00--16:00. Slashes cannot be used in filenames and emailadresses. So a solution with "." or "-" is nice. But I found nothing about this in ISO 8601:2004. Tobias Conradi (Talk) 23:03, 22 June 2007 (UTC)

This article is about the standard. Deviating practices whould not be mixed in. −Woodstone 12:00, 24 June 2007 (UTC)

section 4.4.2 Tobias Conradi (Talk) 01:20, 25 June 2007 (UTC)

Start of the week (continued)

In Arabic, Hebrew, each Chinese language, and others that use their days of the week as a basis, like Indonesian or Swahili, Sunday through Saturday are named Firstday through Seventhday. Eastern Europe and Iceland name Wednesday Midweek. To establish a system based on the agreement of Western Europe's microstates alone and ignore much of the Americas, Asia, traditional Africa, Australia, and East Europe is highly biassed. Considering that Russian, Chinese, Arabic, many English speakers, and some French or Spanish speakers use the old way, this method is not based on superior numbers geographically, population-wise, or linguistically. thecurran Thecurran 09:51, 1 August 2007 (UTC)

While I agree with the point you are making, there is a small error in your text. Russian does not consider Sunday the first day of the week. The Russian names for Tuesday, Thursday and Friday are derived from the numbers two, four and five, respectively. --Oz1cz 07:36, 2 August 2007 (UTC)

Thecurran is also incorrect regarding Chinese, where Monday through Saturday are literally numbered 1 to 6. See Days of the week#Numerical. Indonesia has weeks of 2, 3, 4, 5, 6, 7, 8, 9 and 10 days each, none of which are numbered, which run concurrently. See Eviatar Zerubavel, The Seven Day Circle, pages 55 to 59. In particular, the Indonesian seven-day week is derived from the Sanskrit/Hindi week, all of whose days are named for Hindu deities who represent the planets (it isn't numbered). The Swahili week assigns days one through five to Saturday through Wednesday![1][2] At least he is correct regarding Arabic and Hebrew. — Joe Kress 02:14, 4 August 2007 (UTC)

Wait up, please. First off, I haven't told you my gender so please try to avoid gender-specific pronouns. Secondly, in Russian the word for Wednesday is среда (~=sreda) < средина (~=sredina) (middle), meaning middle of the week like I was trying to explain, which puts Sunday at the beginning. Thirdly, I have close contacts with Indonesia and a minor education in Indonesian. I contend that the Indonesian Sunday-Saturday, hari minggu, hari senin, hari selasa, hari rabu, hari kamis, hari juma'at, and hari sabtu have roots in the Arabic Sunday-Saturday, الأحد (al-’á:ħad), الإثنين (al-’iθnéin), الثلاثاء (aθ-θalaθá’), الأربعاء (al-’árbaʕa’), الخميس (al-χamíːs), الجمعة (aj-júmʕa), and السبت (as-sábt). Remembering that in Indonesia hari means day & minggu means week, so hari minggu is the day that starts the week; Arabic al is basically a definite article; and that Indonesian has a different set of consonants and vowels so to begin with ’->, θ->s, χ->k, ʕ->', yields the following: isnéin->senin, árba'a->rabu, salasá->selasa, kamíːs->kamis, júm'a->juma'at, sábt->sabtu. I don't find it hard to conclude from this that the Indonesian names have Arabic roots, rather than those of Hindu deities. Perhaps, you refer to a minority dialect confined primarily to the largest majority Hindu island, Bali. Bearing in mind that Indonesia is the largest Muslim nation, and that Hinduism as a majority in the majority Malay population is largely confined to a minority of the smaller islands in the archipelago, your source seems to have misconstrued reality. The nature of your conversation seems to imply a great lack of knowledge on my part in an inflammatory way. I yearn to be enlightened, but I would like you to please tone down your responses. This section is getting pretty big. I think I'll continue it in a new section at the bottom. Thecurran 22:54, 9 August 2007 (UTC)

I was partially wrong about Chinese. I misinterpreted the fact that China starts the week on Sunday (yet again) to mean that it starts the numbering on Sunday, when it really starts numbering on Monday, like Joe Kress said. For the sake of completeness, I'd like to point out that the Indonesian days seem to differ drastically from the referred Sanskrit & Hindi Sunday-Saturday, रविवार ravivār (Ravi=Sun), सोमवार somavār (Soma=Moon), मंगलवार mãgalavār (Mangala=Mars), बुधवार budhvār (Budha=Mercury), गुरूवार gurūvār (Guru=Jupiter), शुक्रवार shukrvār (Shukra=Venus), शनिवार shanivār (Shani=Saturn), where vār=day. I also note that Portuguese, Greek, Georgian, Farsi, Dari, Tajik, Kazakh, Turkish, Vietnamese, Ecclesiastical Latin, and others besides the Icelandic, Arabic, and Hebrew I mentioned number the days Sunday-Saturday as 1-7 in their names. Beyond that, Icelandic, Polish, Czech, Serbian, Slovenian, Macedonian, Hungarian, Russian, Ukranian, German, and Finnish all call Wednesday the day in the middle of the week, making Sunday the start. My remark on Swahili was meant to note that it too did not mark Monday as Day 1. Much of Swahili is related to Arabic or loaned from it, but what I wrote was misleading. It would seem that the former Warsaw nations followed the original Sunday-Saturday when naming days and that the first to have a god's name removed was midweek Wednesday. The rest may have had their God's name removed after following the French Republican model of a Monday-Sunday week. Nevertheless, I think it is safe to say that most of the world follows the millenia-old Sunday-Saturday model rather than the one imposed anarchically by the French Republic and enshrining this minority view into the ISO ignores most of the poulation, geography, linguistics, history, culture, and tradition of the world, which is contrary to NPOV & should be contrary to ISO. I invite further discussion but please do so in the bottom section, "Start of the Week (Continued)". Thecurran 00:07, 10 August 2007 (UTC)

I think all of this discussion is moot, because Saturday/Sunday are commonly called the "weekend". That is how common people think of it. −Woodstone 09:05, 10 August 2007 (UTC)

In English the beginning (first) and the end (last) are both ends so saying end is ambiguous. Thus saying that Saturday and Sunday are the weekend days might imply that one is last and the other is first. Boris58 14:51, 5 September 2007 (UTC) 14:51, 5 September 2007 (UTC)

To help decrease my transfer size, I started a new section. Please, for continuity read the earlier one, "Start of the Week". Thecurran 00:07, 10 August 2007 (UTC)

For continuity, I have transferred the immediately preceding discussion to the new section. No identification of gender was intended. English is handicapped because it does not have a neutral singular personal pronoun, so "he" includes "she" in normal writing. To explicitly include females we are left with rather stilted phrases like "he or she" or "s/he" if we do not know the gender of the writer. To show the proper respect, English speakers must know the gender of the writer.

The Slavic use of "middle" for Wednesday does indeed imply that Sunday in the first day of the week, but the simultaneous use of "second", "fourth" and "fifth" for Tuesday, Thursday and Friday even more strongly implies that Monday is the first day of the week. So Slavic names for the days of the week are, at the very least, rather ambiguous regarding the first day of the week. Brown (see Days of the week#References) shows that languages name the days of the week, when they are first appraised of the concept of a seven-day week, either by the use of salient words, like "Resurrection" for Sunday in Russian or "no work" in other Slavic languages, or bilingual speakers may adopt another language's word for an important day, such as "Sabath" for Saturday in the Slavic languages, obtained from Greek, which obtained it from Hebrew. Thus languages acquire names for the most important days first, often Saturday and Sunday, and later for the other days of the week, in the order Monday, Friday, Tuesday, Thursday, leaving Wednesday as the last day to get its own name. So Wednesday's name, "middle", did not involve the removal of a god's name, it was just the least important day.

This view also supports the use of "Week: Day" for Sunday in Chinese as an important day while simply numbering the other days of the week, which shows their secondary status. In this case, a first day means the first day after an important day. Although Swahili does indeed incorporate many Arabic words, its basic words are similar to those of other Bantu languages, so only the important days of Thursday and Friday have Arabic names, while all other days of the week have Swahili/Bantu names, which are simply numbers, again showing their secondary status. Its first day means the first day after the most important day in Islam, Friday. Thus the "first day of the week" is a red herring, not implying the "start of the week", but actually implying unimportance.

The important days of the week in Arabic and Ecclesiastical Latin have salient native words, "gathering" for Friday in Arabic and "Lord" for Sunday in Ecclesiastical Latin. But in these languages, the numbered days of the week do not imply position relative to the important day, but are simple translations of the numbered days in Hebrew. In all three languages, numbered days of the week indicate they are less important (or unimportant) relative to the important day, Friday in Arabic, Saturday in Hebrew, and Sunday in Ecclesiastical Latin. In summary, numbered days of the week cannot be used to indicate the "start of the week".

Thanks for explaining the Indonesian names for the days of the week. Javanese calendar confirms them, but also mentions the Pawukon calendar described by Zeruvabel. The latter is indeed mostly used on Bali, but is also used on Java for special occasions. — Joe Kress 02:35, 11 August 2007 (UTC)

The use of second for Tuesday my imply second after "Lord's day" without implying that it is the second day of the week. Boris58 14:32, 5 September 2007 (UTC) 14:32, 5 September 2007 (UTC)