Talk:ISO 8601

From Wikipedia, the free encyclopedia

Some people have proposed using ISO 8601 for wikipedia dates. For more of this discussion, see Wikipedia talk:Manual of Style (dates and numbers)

Contents

[edit] BC

BC dates are handled in ISO 8601 with a minus symbol. Beware that before AD 1 (0001) there is, BC 1 which is 0000, so BC 2 is -0001 and so on. I found a draft copy of the standrd at http://www.ray-connolly.fsnet.co.uk/ISO8601-2000_Draft-20001215_ISO-TC154-N362_Final.PDF (anon)

[edit] 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 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

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

-- 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

[edit] Y10K

The Long Now foundation suggests that years should be written with five digits (ie 02003 for the year 2003) in order to avoid the Year 10,000 problem.

This is pointless: all it does is push the problem forward a few years to 100,000, and situation already exists for dates in the past (-10,000 and earlier.) May as well accept that the year number can have a varying number of digits -( 18:57 22 Jun 2003 (UTC)

Without seeing that I assumed they were serious! Brianjd

[edit] 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)

[edit] scripting error

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

The current time is 2007-04-8T19:18Z
(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 2007–04–08T19:18Z.

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)?

[edit] 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)

[edit] 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)


[edit] 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)

[edit] 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: o-W14-7. 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 – {{ ISOYEAR|2004|12|31}} gives 2004, today: {{ ISOYEAR|2007|04|8}} gives 2007
  • Template:ISOWEEK – {{ ISOWEEK|2004|12|31}} gives 53, today: {{ ISOWEEK|2007|04|8}} gives 14
  • Template:ISOWEEKDAY – {{ ISOWEEKDAY|2004|12|31}} gives 5, today: {{ ISOWEEKDAY|2007|04|8}} gives 7
  • Template:ISOWEEKDATE – {{ ISOWEEKDATE|2004|12|31}} gives 2004-W53-5, today: {{ ISOWEEKDATE}} gives 2007-W14-7

Examples where the ISO year is three days into the next gregorian year:

  • {{ ISOWEEKDATE|2009|12|31}} gives 2009-W53-4
  • {{ ISOWEEKDATE|2010|1|1}} gives 2009-W53-5
  • {{ ISOWEEKDATE|2010|1|2}} gives 2009-W53-6
  • {{ ISOWEEKDATE|2010|1|3}} gives 2009-W53-7
  • {{ ISOWEEKDATE|2010|1|4}} gives 2010-W01-1

Examples where the ISO year is three days into the previous gregorian year:

  • {{ ISOWEEKDATE|2008|12|28}} gives 2008-W52-7
  • {{ ISOWEEKDATE|2008|12|29}} gives 2009-W01-1
  • {{ ISOWEEKDATE|2008|12|30}} gives 2009-W01-2
  • {{ ISOWEEKDATE|2008|12|31}} gives 2009-W01-3
  • {{ ISOWEEKDATE|2009|1|1}} gives 2009-W01-4

Nsaa 12:26, 14 November 2006 (UTC)

[edit] 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

[edit] 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)

[edit] BCE and divs

The class should apply equally well to divs. As we are not presenting tabular data, it is advisable to use divs.

Either BC or BCE (and AD or CE) should be used, but not both. I favor CE, if only because it's not Latin, and not religious. (Ideally, time shouldn't be religious, but we are talking about the Gregorian calendar.) However, I don't really care, just as long as we're not using both. It was by carelessness that I added BCE instead of BC—I was focusing on clear prose, so I ignored a distracting debate. (Careless, as in without worry, not haphazardly.) —Daelin @ 2006–01–08 16:21Z

[edit] -

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

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] "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)

[edit] Various observations on Main Page and Talk

[edit] Main Page

[edit] 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)

[edit] 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)

[edit] Talk

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)
Retrieved from "http://en.wikipedia.org../../../i/s/o/Talk%7EISO_8601_b497.html"