Forum Moderators: open
04/03/02 in UK = fourth of march 2002
04/03/02 in US = third of april 2002
if the month is in full then the rest will fall into place...
That isn't neccesarily the case. Take the date format widely used in the travel/reservations industry:
Is that earlier this year, or early next year?
Normally, in context, you can tell. And it was much more obvious when you saw dates like 02JAN99. But, however the month is rendered, there is a strong case for not abbreviating years to two digits.
I hope people here take the time to follow up the 4 links I provided in earler postings.
Is there anyone else here convinced enough to make the change ? (Thanks moonbiter, ergophobe, victor, PurpleMartin, and pageone for your earlier support !)
W3C have a note about ISO 8601 on their web-site, and many new protocols are now using it.
It is, g1smd, a lot of people read that the other way. In a lot of places outside the U.S. today is 03-07-2002. It's actually logical, since it corresponds with 3Jul02.
You can browse here [search.aol.co.uk] to see it.
In a lot of places outside the U.S. today is 03-07-2002.
I was born and raised in the USA and they didn't teach this stuff in school back in the 70's! Not once did YYYY-MM-DD come into my life, until this thread started. I was in the service for 4 years and lived by the Julian Date.
Hmmm, just did a quick search on julian date and found this...
> Calendar dates — year, month, and day — are more problematic. Various calendar systems have been in use at different times and places around the world. This application deals with only two: the Gregorian calendar, now used universally for civil purposes, and the Julian calendar, its predecessor in the western world. As used here, the two calendars have identical month names and number of days in each month, and differ only in the rule for leap years. The Julian calendar has a leap year every fourth year, while the Gregorian calendar has a leap year every fourth year except century years not exactly divisible by 400.
That coming from the U.S. Naval Observatory [aa.usno.navy.mil]. Now what I do? Switch all the dates back? Nah, I'll stick with the recommendations in this thread for now. I've already gotten used to the new format.
P.S. Now that I think about it, the rollover to the 21st Century created a slight problem with date formats. Any dates between **32 and **99 are easily recognizable by their last two digits. Not so with the rollover to 00. Now we have 31 years of confusion to look forward to.
ISO 8601 is for machine readable code. It is designed to be read and understood by machines. It is not designed actually to be displayed. It may be used by scientists, but that's a specialist field.
The vast majority of my visitors do not understand the ISO 8601, and I do not see why I should force them to learn it just because I think it would make life easier.
What's the big deal? You should use ISO 8601 in, say, <del> and <ins> tags, which are tags which should be removed before publication anyway.
The full ISO 8601 specification is:
YYYY-MM-DDThh:mm:ssTZD
where:
YYYY is the year in four-digit format;
MM is the month in two-digit format;
DD is the day in two-digit format;
hh is the hour in two-digit format (military time);
mm is the minute in two-digit format;
ss is the second in two-digit format;
and TZD is the time zone; either Z for UCT or +hh:mm for times ahead of UTC, or -hh:mm for times behind UTC (not all time zones are whole hours away from UTC).
Imagine the latest blockbuster film is showing at the local cinema at:
2002-08-14T19:30:00+02:00
Should they put that on their site?
My db crap though i always do YYYY-MM-DD
So where exactly do we draw the line between dates displayed on a html or xml web page, or in a document, for reading; and those read by a machine which crawls those pages and indexes them for a search engine?
> 2002-08-14T19:30:00+02:00
> Should they put that on their site?
They should use the 2002-08-14 date format, and the use of 24-hour time does now seem to start happening in the US - Europeans have been happy with it for decades - but there is no need for the T in human reading. Indication of time zone is useful, however old style EST could be Eastern Standard Time US, European Summer Time, or Eastern Standard Time Australia. The use of -0200 type formats is already well established in things like email headers designed to be read by both machines and humans. However, the date format in email headers was defined before ISO 8601 was well known. Date stamps inside MPEG movies are always ISO8601 format. It's surprising just where it is used... already more places than you could imagine.
And you can't have your cake and eat it. You either use the ISO 8601 standard or you don't -- you certainly shouldn't use part of it.
You're asking me to tell visitors to my site that they have to learn a new format for reading dates, one which the vast majority of them are unfamiliar with and which nobody uses in the normal course of their everyday lives. That is bad design, period. It is tantamount to saying, "If you don't do things the way I say you must, bad luck, because my SE rankings are more important to me than your being able to understand what I write."
SE rankings mean nothing if your content is illegible. We have to give people information they can actually use, not force them to learn our way of doing it. All you need to do is to write the month out in full and the year in four digits, and it will be understood far more quickly by far more people. Is that such a hard concept to grasp? A web page should be human readable. (The HTML code itself, of course, can be as machine-readable as you like, but not the result.)
It is now (using the condensed format) 200207091852+02, or thereabouts.
Of course, that's according to the Gregorian calendar, which not all cultures use. Perhaps the next step is a standard which incorporates the Jewish and Islamic calendars?
I was born and raised in the USA and they didn't teach this stuff in school back in the 70's! Not once did YYYY-MM- DD come into my life, until this thread started.
I could say the same to first part, but this date format is something I came up with on my own (I'm not saying I was the first, just that I never read about it anywhere before I started using it). Why? Simple, I keep archived backups of the projects I work on. The only way on most computers to get a file listing to sort by name is alphabetical. If you name your archive files
project-03-jan-2002
Then your backups are in order all right, but the order is
April
August
December
February
January
July
June
Etc
With the naming system that g1smd proposes, you archive your files with names like
2002-03-29_project1
2002-04-30_project2
Sorts alphabetically and numerically.
I still use other date formats when it is text intended to be read by a human in a given language and context. So when I write in French it is always 3 fevrier 2002 and in English, I spell the month out and use a four digit year so there is no ambiguity.
Whenever I think that I can get away with "computerese", though, I prefer the yyyy-mm-dd format because
1. it's unambiguous
2. it works as an alphabetic or numeric sort
and now I can add
3. it's an ISO standard.
Thanks so much for bringing this latter point to my attention!
Cheers,
Tom
Search for 'military' in the page at this link: [byte.com...] . Times have moved on.
This is useful: [naggum.no...] check out the date it was written as well.
also [wm.edu...] maybe?
> The vast majority of my visitors do not understand the ISO 8601, and I do not see why I should force them to learn it just because I think it would make life easier.
Where-ever you are in the world, about 99% of potential visitors to your web site are outside of your country. The idea of ISO 8601 is to be language neutral, simple, relatively obvious, and not easy to confuse with any other format already in use in some place.
Language neutral means 'all digits'. Not confused with any other format therefore rules out 01-02-03 and 01-02-2003 . 01-2003-02 is preposterous. This leaves 2003-02-01, which as I said upstairs:
> ... that the only language-neutral, unambiguous (_once_you_have_learnt_one_simple_rule_), globally-agreed standard is YYYY-MM-DD.
That simple rule: Only YYYY-MM-DD is valid, yyyy-dd-mm is NOT valid; as opposed to looking at a date like 01-02-2003 and understanding what is meant.
In fact, your interpretation of 01-02-2003 depends on...
-Whether you yourself are European or American.
- Whether you are sure you know...
- - That the date was written by a European or by an American.
- - That the information originated either from Europe or from America.
- - That the information was targeted at a European or American readership.
- - That you actually knew that two different methods were in use on the opposite sides of the Atlantic.
- - ...or any combination of the above.
In other words you have absolutely no idea if you read it right or not.
BTW: ISO 8601 is also known as ANSI X3.30 and NIST FIPS 4-1 .
The year 2000 caused a problem in our perception of date formats.
I utilize a web based application for tracking and just realized it uses the 2002/07/09 format. Its funny how I've been actively looking at date and time formats when visiting websites. ;)
I'm with rewboss all the way on this one. If the page we present to the world is intended to be read, understood and used by PEOPLE from all nationalities and levels of education/intelligence/age groups, then we have an obligation to make that page absolutely free from misunderstanding... and standards be damned!
If I design a site for a holiday resort and the booking form allows arrival and departure dates to be interpreted differently, think of how much sh*t will hit the fan when the customer thinks they are booking for 7th March and the resort makes the booking for 3rd July.... a lawyers smorgasboard!
Don't assume dates will be read the same way by everyone... I can assure you absolutely they will not.
ISO 8601 is not understood by Mr and Ms Average-Surfer.
ISO 8601 may be used in technical documents. Maybe the military use it as well. These are specialist fields and Mr and Ms Average-Surfer -- the people I am designing my sites for, for the most part do not understand ISO 8601.
As for the international issue...
If I write a page in English, I will write the date as 10th July 2002, and the time as 11.45am. The chances are that anyone who doesn't understand that format won't understand the rest of the page and won't be reading it.
If I write a page in German, I will write the date as 10. Juli 2002, and the time as 11:45 Uhr. Wahrscheinlich werden diejenigen, die dieses Format nicht verstehen, den Rest der Seite auch nicht verstehen und auch nicht lesen.
If I write a page in Russian, I will write the date as 10 iul' 2002, and the time as 11:45 ch. Yesli ne ponimayut... uh, well I think you get the point.
If you want my site to be accessible to everybody no matter what their native language, what must I do to achieve this? Following this line of logic, we must have no text at all on any of our websites.
You cannot force the issue. People will use what they are used to, and that's that.
Did you know that the USA adopted the metric system for its weights and measures as the only legal standard? But you won't find many people using it because their great-great-gandparents used (actually misused) the First Amendment to assert their right to use whichever standard they wanted, and they wanted the old system.
In Britain, bus and train timetables are written in 24-hour format. But you will usually find a little diagram somewhere explaining how the 24-hour format works, because few Brits use the 24-hour clock for anything except bus and train timetables.
Just because a standard exists doesn't mean it is always sensible to use it; certainly not without thinking through the consequences.
We try our best to stick to the W3C recommendations for markup because, in theory at least, it makes our sites faster, more likely to be cross-browser compatible and also (if the software giants play fair) forwards compatible. But markup isn't for Mr and Ms Average-Surfer, it's for Mr and Ms Web-Designer, Internet Explorer and friends.
That said many of my co-workers still preferred the format they had grown up with, even though it was undisputable that it was more likely to cause misunderstandings then YYYY-MM-DD. The arguments were often in line with "It reflects the natural way humans think." But when three people all (at the same time) claimed that their own different way of writing dates represented "the natural way humans think" it became quite obvious to everyone that there is no such way but merely what one is used to.
Therefore, when designing software I use the locale settings of the operating system when displaying (and accepting) dates, but when it comes to web-pages and printed documentation it will always be in YYYY-MM-DD. I motivate that with it being better to use a format that some people will have to stop and think a little about but no one will misunderstand then a format that some will get right immediately but others will misunderstand. It being an international standard is of course an extra plus.
What I found was that although most of them never had heard of ISO 8601 or YYYY-MM-DD formats no one ever misunderstood a date in YYYY-MM-DD format. Some had to stop and think a little, but they all understood it without any explanation from me.
There are so many other things that we could standardize. Here are some examples:
Weights and measures: The metric system is used in most countries in the world. It is also the official system in the only major country that doesn't regularly use it. There is therefore no reason to use inches, pounds, miles etc on the web. Goodbye 17" monitors, hello 43cm monitors.
Numerical notation: Decimal points and thousands separators vary wildly from country to country. In deference to the fact that the International System of weights and measures, used by scientists, was developed in France, we should use the French system: commas as decimal points, and periods to separate the thousands.
Mathematical notation: The divide-by symbol also varies from country to country. Since slashes are used to approximate vulgar fractions, we should adopt the colon, as used in many European countries.
Paper format: A constant source of problems is the issue of paper format, which also varies from country to country. In order to ensure that a document written in Europe will fit on an American standard letter (or vice versa), it must be reduced to about 92% original size. Since the German Industrial Norm (DIN) has proved so successful and been adopted by all European countries, this should be the format used. An interim transitional period should be granted to allow Americans to replace or reconfigure their printers and photocopiers.
Postal addresses: There are many anomolies here. For instance, the German Post insists that, on overseas letters, the country should be on the last line of the letter and the only line written in block capitals; the British Post Office, however, insists that the town or city name be written in block capitals and the post code to be the last item, even on mail coming from abroad. Postal addresses badly need to be standardized. (This will also help webmasters design forms for shipping information.) French is the official language of the International Postal Union, so country names should be written in French.
Clearly a date of 1/2/3 will work clearly and unambiguously only if you are absolutely sure the person reading it understands your conventions.
On the other hand, 2001-02-03 is only probably unambiguous and may cause some head-scratching before the reader twigs -- so it is not 100% clear either.
Both those "other hand" problems due to the (as yet) non-universal acceptance of ISO8601.
I suggest the answer (given we are in a transitional period) is to use ISO8601 and (if your site/audience) need it, a local format too:
2001-02-03 (3rd Mar) would cover a lot of the cases I use.
However, there is also a need for a strictly numerical date format in many web-applications.
One example would be applications where visitors might modify or enter date. Yes, it can be solved with three drop down lists: 1-31, January-December and years, but this type of interface tends to be a bit annoying when there are many dates to enter.
Another would be large lists of events, say financial transactions, where you are interested in the distance (time wise) between them. Although everyone would understand 11 March 2002 and 9 August 2002 most people will count on their fingers to find out how many months there are between them. A strictly numerical format is more appropriate in that case.
A third example is when other parts of the web-application are using a numerical format of one reason or another (maybe one of the two above). Then it can be a good idea to use the numerical format even where you otherwise might have used "11 June 2002" since consistency also is important.
Anyway, my point is not really the examples as such, but merely that sometimes a strict numerical date format might be desirable.
On a side note: Some years ago I developed a software for international mailing lists (snail mail that is) and got very frustrated trying to support all the different address formats, especially the UK one. As you pointed out, most of the time it is impossible to adhere to both the originating country’s address standard and the UK one at the same time.
Variable - Current Date and Time
<%=lastrevisedn%>
<%
'*** date now
lastrevised = now
lrtime = formatdatetime(lastrevised,vbshorttime)
edward = formatdatetime(lastrevised,vblongtime)
edward = left(edward,len(edward)-3)
arredward = split(edward,":")
edwardfoo = arredward(2)
lrdate = formatdatetime(lastrevised,vbshortdate)
arrdate = split(lrdate,"/")
if arrdate(0)<10 then arrdate(0) = "0" & arrdate(0)
if arrdate(1)<10 then arrdate(1) = "0" & arrdate(1)
lrdate = arrdate(2) & "-" & arrdate(0) & "-" & arrdate(1)
lastrevisedn = lrdate & " " & lrtime & ":" & edwardfoo & " " & "UTC"
%>
Variable - Last Revised Date
<%=lastrevisedt%>
<%
'*** date then
lastrevised = rstemp("lastrevised")
lrtime = formatdatetime(lastrevised,vbshorttime)
edward = formatdatetime(lastrevised,vblongtime)
edward = left(edward,len(edward)-3)
arredward = split(edward,":")
edwardfoo = arredward(2)
lrdate = formatdatetime(lastrevised,vbshortdate)
arrdate = split(lrdate,"/")
if arrdate(0)<10 then arrdate(0) = "0" & arrdate(0)
if arrdate(1)<10 then arrdate(1) = "0" & arrdate(1)
lrdate = arrDate(2) & "-" & arrdate(0) & "-" & arrdate(1)
lastrevisedt = lrdate & " " & lrtime & ":" & edwardfoo & " " & "UTC"
%>
You may want to change the naming structure, that's my programmer being funny. His response; "Do you have to have milliseconds?" My response; "Yes, I have to have milliseconds!"
The current date and time is...
2002-07-11 17:11:19 UTC
Your programmer may also be interested in:
[exit109.com...]
[delphi32.com...]
[cs.tut.fi...]
[pvv.org...]
[personal.ecu.edu...]
[phys.uu.nl...]
[cs.waikato.ac.nz...]
[merlyn.demon.co.uk...]
[cpearson.com...]
[whizkidtech.net...]
I think that is all of the ones with program code in them.
I got your mail. Haven't had time to deal with it. Give me a few days (at least).
<!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%Y-%m-%d %H:%M:%S UTC%Z" -->
Produces this...
2002-07-03 19:03:05 UTC-0700
<!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%Y-%m-%d %H:%M:%S UTC" -->
Produces this...
2002-07-03 19:03:05 UTC
BTW, Standard time zone is UTC-0800 hours here in Sunny Southern California. Due to daylight saving time adjustment of +1 hour, the current time zone offset is UTC-0700 hours.
UTC means Universal Time, Coordinated or Coordinated Universal Time.
P.S. If you need a double space between date and time, just add two non-breaking back spaces between these two (%d %H)
2002-07-03 19:03:05 UTC-0700 should be:
2002-07-03T19:03:05-07:00 or:
20020703190305-07
One example would be applications where visitors might modify or enter date. Yes, it can be solved with three drop down lists: 1-31, January-December and years, but this type of interface tends to be a bit annoying when there are many dates to enter
Another would be large lists of events, say financial transactions, where you are interested in the distance (time wise) between them. Although everyone would understand 11 March 2002 and 9 August 2002 most people will count on their fingers to find out how many months there are between them. A strictly numerical format is more appropriate in that case.
Also, in most everyday cases, people don't think in terms of "first month, second month, third month...", they think "January, February, March..." People booking their holidays will think "Leaving 14th July, coming back 2nd August". If they are then forced to start thinking 7/14 - 8/2 (because they have to enter numerical dates to book their flights), then they start counting on their fingers.
2002 VII. 03. (or without the 0).
Strange, we still use that term in the UK.
g1smd, it seems as if, rather than suggesting that we use the ISO standard for dates, you're banging people with a stick and saying "you MUST use this because it's the standard!" As others have pointed out, it may be a standard, but that doesn't mean we have to use it. CSS layout is now considered the "proper" way to lay out a page, but that might not work for all audiences.
Also, not everything the W3C publishes should be taken as gospel. They're not perfect and they do get it wrong sometimes, or rather get it half right but need to work on it some more.
I think NATO tried that format for a time. It was a compromise because the Brits and the French couldn't agree the language for the abbreviated 3-letter month names. It never caught on as a standard.
Zaccix:
....it may be a standard, but that doesn't mean we have to use it.....might not work for all audiences.
I think you've hit the key points here. There are undoubtable many websites whose users would benefit from the ISO standard date format -- almost anything with an international audience for example.
But there are many today which probably would not. It's good that g1smd has raised this issue -- it gives the concerned webmaster a chance to consider it, and maybe experiment with some changes.
If a few people report back that ISO dates triple their conversions, the whole thing may snowball.
And, even if it doesn't today, it seems reasonable to keep the issue under review -- if a whole generation is growing up using ISO 8601, then the proportion of sites whose users benefit from it will steadily increase. Starting, I'd guess, with the important international youth market.
"Please don't use GMT, that term went obsolete in 1971."
Strange, we still use that term in the UK.
Tapolyai:I think Russia uses Roman numerals for months; rather odd, seeing as the Cyrillic alphabet doesn't have either a V or an I.
2002 VII. 03. (or without the 0)
I think NATO tried that format for a time. It was a compromise because the Brits and the French couldn't agree the language for the abbreviated 3-letter month names. It never caught on as a standard.
But it didn't catch on in Britain and France, and this illustrates the problem: it's very difficult to force people to use a standard they are unfamiliar with.
For ISO8601 to be readily accepted by all would require that all countries in the world enact legislation to this end. Most countries simply won't bother. Many European countries will probably accept it grudgingly, but it will take several generations. Americans will most likely simply refuse, and will do what they did with metric weights and measures: invoke the First Amendment and claim it means they can express their dates in whatever form they choose.
Even if we could get all governments to co-operate, I estimate it would take another 40 years to implement.
Since this discussion has started, and especially since I have been more or less told that YYYY-MM-DD is practically taking over the world, I have kept my eyes peeled for any evidence. I have not seen a single incidence of this format being used anywhere at all, except for a few I have been specifically pointed to in this thread.
