Welcome to WebmasterWorld Guest from 220.127.116.11
Forum Moderators: incrediBILL
> 3 July, 2002
Sorry. No use if you don't speak English.
> 2002-07-03 14:26:20 PST
Nice, YYYY-MM-DD, but it may be useful to stick a flag somewhere to say that PST = UTC - 0800 (or else convert the display entirely to UTC) - unless all your readers are in the PST time zone themselves. Please don't use GMT, that term went obsolete in 1971.
> P.S. We just switched after reading the W3C specification.
That Spec has been around for 5 years. The XML people lapped it up, but it's slower elsewhere. Astronomers have worked that way for 200 years, even some in the US like [umbra.nascom.nasa.gov...]
>> Everyone understand it
> 7th March, am I right?
I knew someone would ask that.
Today is 07-03-2002 in the US (MM-DD-YYYY), and 03-07-2002 in Europe (DD-MM-YYYY). Both can be misread.
2002-07-03 is always YYYY-MM-DD because no-one anywhere uses YYYY-DD-MM. The only place that DD-MM turns up is in DD-MM-YYYY, which can be misread for MM-DD-YYYY for the first 12 days each month.
Additionally, YYYY-MM-DD is the Official Standard that your country signed up to sometime between 1968 and 1976 (this is true for just about every 'Western' nation, as well as many in developing countries).
DD-MM-YYYY or MM-DD-YYYY? Who decides? Best use neither.
> 15:03 PST Wednesday July 3, 2002
Really hard to follow when presented in a list Hours-Minutes-Zone-Day-Month-Day-Year. Try reformatting that as:
2002 Jul 03 [Wed] 15:03 PST and seeing a nice improvement in readibility.
> 03 Jul 02
> (concise and readable regardless of which side of the pond you come from)
That means 2003 July 02 to most Asian people, they (China/Korea/Taiwan/Japan/Thailand) write the Year first (as does Sweden, Finland, some Eastern Europe states, and others)
I am appalled at the use of two digit years. Four digts avoids the Century ambiguity problem. (I still see some sites with broken Java Script showing this year as 103, 1903, or even 19103. Sheeesh!).
> I figured but there really isn't much of a standard here. I never know what it is. I always assume dd-mm-yyyy or yyyy-mm-dd.
YYYY-MM-DD is the standard, as referenced in the links in the first posting in this thread.
[edited by: g1smd at 11:18 pm (utc) on July 3, 2002]
I'm a Brit too, and I don't think I'd ever read that as anything other than 3rd July 2002. Maybe it's a regional thing?
A bit like pushcat, I strive to met local expectations. I often use ISO8601 (yyyy-mm-dd) because the sites are international, but usually qualify it with a "translation":
2002-07-03 (do 2 juli) -- Dutch
2002-07-03 (Thu 2 July) -- UK/English
This involved a lot of lookup and code for dates. Courtesy costs, I guess.
British Standard BS EN 28601:2000 [aka ISO 8601:2000] replaces BS EN 28601:1991 which previously replaced BS 7151:1988 [aka ISO 8601:1988]. ISO 8601:1988 amalgamated and superceded ISO 2014, ISO 2015, ISO 2711, ISO 3307, and ISO 4031, from various dates in the 1970s.
ISO 8601:1988 was published in many places:
European Norm: EN 28601:1992 ____ USA Standard: ANSI X3.30-1985(R1991) ____ USA Standard: NIST FIPS 4-1 [now FIPS 4-2] ____ Canada: CSA Z234.5:1989 ____ Australia: AS 3802:1997 ____ South Africa: ARP 010:1989 ____ Austria: OENORM EN 28601 ____ Belgium: NBN EN 28601 (1993) ____ Czech Republic: CSN EN 28601 ____ Denmark: DS/EN 28601 ____ Finland: SFS-EN 28601 ____ France: NF EN 28601 (1993) ____ Germany: DIN EN 28601 (1993) & DIN 5008 (1996) ____ Greece: ELOT EN 28601 ____ Iceland: IST EN 28601:1992 ____ Ireland: IS/EN 28601:1993 ____ Italy: UNI EN 28601 (1993) ____ Luxembourg: ITM-EN 28601 ____ Netherlands: NEN ISO 8601 (1994) & NEN EN 28601 (1994) ____ Norway: NS-ISO 8601 ____ Portugal: EN 28601 ____ Spain: UNE EN 28601 ____ Sweden: SS-EN 28601 (1991) ____ Switzerland: SN-EN 28601-1994 ____ United Kingdom: BS EN 28601:1992 (replaces BS 7151) ____ Poland: PN-90/N-01204 ____ Taiwan (ROC): CNS 7648 ____ Thailand: TIS 1111-2535 ____ China: GB/T 7408-94 = Adopted directly from ISO 8601:1988 ____ Hong Kong: ISO 8601____ India: IS 7900:1976 = Method for writing calendar dates in all numeric forms (IS 7900:1976 = ISO/R 2014:1971) ____ India: IS 10934:1984 = Representation of the time date (24 hr) - (IS 10934:1984 = ISO 3307:1975) ____ Japan: JIS X 0301-1992 [previously JIS X 0301-1977] = Identification Code of Dates ____ Japan: JIS X 0302-1977 = Identification Code of Times ____ Korea: KS A 5401-1972 = Writing of calendar dates in all-numeric form ____ Korea: KS A 5402-1986 = Numbering of weeks ____ Korea: KS C 5610-1992 = Identification code of dates and times ____ Philippines: PNS 293-1991 = Representation of date and times ____ Thailand: TIS 1111:2535 = Representation of Date and Time (1992).
ISO/R 2014:1971 = was revised to form ISO 2014:1976, and then replaced by ISO/IEC 8601:1988 ____ ISO 3307:1975 = This standard is replaced by ISO 8601:1988 ____ ISO 8601:1988 = has been replaced by ISO 8601:2000.
[edited by: g1smd at 12:27 am (utc) on July 4, 2002]
P.S. We just switched after reading the W3C specification. It used to be...
This page last updated: 07.03.2002 14:26:20 PST
P.S.S. We just switched again after reading g1smd's suggestion. It is now...
This site last updated: 2002-07-03 19:03:05 UTC-0700
And, for you FrontPage users, here is the slightly modified webbot code that you can use to create the above date and time stamp.
<!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%Y-%m-%d %H:%M:%S UTC%Z" -->
It works, I tested it! It should automatically pull the time from your server and then calculate the correct UTC offset. I believe that is how it should work, correct me if I'm wrong.
BTW, Standard time zone is UTC-8 hours here is Sunny Southern California. Due to daylight saving time adjustment of +1 hour, the current time zone offset is UTC-7 hours.
UTC means Universal Time, Coordinated or Coordinated Universal Time.
Okay, I think this is taking it just a little too far! ;)
Southeast Asia: YYYY-MM-DD
There is much scope for confusion. But how you format the date really depends, at least in part, what it's for. If it's necessary for your visitors to understand the date, the month should be written out and the year given in 4-digit format: that way, there's no risk of confusing dates, months and years. In many cases, it is often appropriate to include the day of the week as well, especially if you're advertizing events (quickly now, will you be free on 24th July? Okay, are you likely to be free on Wednesday, 24th July?). Also, people generally find it hard to process a series of numbers.
If it is not necessary for your visitors to understand the date, it shouldn't be there anyway: it merely adds clutter.
Here's something that intrigues me:
> 3 July, 2002
Sorry. No use if you don't speak English.
I work in English and German, so I write my dates in German on German pages, and in English on English pages. Easy. If you can't be bothered to make life easier for your visitors, you shouldn't be designing websites.
When you look back at the above page in a few years time, will you know if March or October is the date?
There is also relevance to search engines here. If you search for '07-04-2002' expecting 7th April, you will get all the US results for July 4 in your search. ISO 8601 YYYY-MM-DD will solve this. Searching for 7th April will miss sites that have Apr 07, April 07, Avril 07 etc. ISO 8601 will solve that. Most XML schemas already allow only dates conforming to ISO 8601, so this is where we are heading. Why not just adopt it. It will make things a lot easier in the long run.
This is a useful document: [fred.bone.dial.pipex.com...]
1. Something about Python (the programming language).
2. Usage stats for the Solar Data Analysis Center (2 pages, one for the week, another for the whole month)
3. Information about an MS-DOS utility called batmenu, in German.
4. A default directory listing
5. Another default directory listing
6. A third default directory listing
7. OMG! Another default directory listing
8. Something about illegal immigration in Chile (Spanish)
9. Would you believe it? A default directory listing...
The scary thing is what it said at the top of the search: "1-10 of about 23,500". I can't see myself ever doing a search for a date in ISO8601.
Note also that the vast majority of internet users don't know what ISO8601 is, or that they should be looking at dates in that format. They are not technical people, and if they are searching for a particular news item on a particular date, they will type the date in in whichever format they are most familiar with. And that will almost certainly not be in ISO8601 format, unless they happen to be from Korea.
Sorry to contradict, but july is translated:
I'm sure there are many more examples. So I guess the number stays the best way to write a date.
And just from a logical point of view, either DD-MM-YYYY or YYYY-MM-DD makes more sense. You either go from the smallest to the biggest time frame or the opposite.
I hear what you say about 1999-01-24, however several of those Indexes are for images galleries sorted by date in Year-Month-Day order.
Now try another date like 2001-04-07 [google.com...] .
You'll see several document titles with that date in them, and many documents using the ISO format internally (There are also a few mix ups where it is grabbing some digits from a time).
However, 2000-04-07 gives even more hits [google.com...] .
> I can't see myself ever doing a search for a date in ISO8601.
In real life, you would probably combine the date with other search words.
Try [google.com...] for example.
NewsML, the XML Schema format for the distribution of news (by Reuters and such) is based on ISO 8601 .
Repositiories for news (not Usenet Newsgroups) are therefore already using this format.
However (correction), I just checked the Date Format used by [groups.google.com...] (formerly [dejanews.com...] ) the Web-based archive of UseNet, and they are already using YYYY-MM-DD throughout the MESSAGE HEADERS on the searchable archive. They use long format 22 June 2002 elsewhere.
I hear what you say about 1999-01-24, however several of those Indexes are for images galleries sorted by date in Year-Month-Day orderExactly. Do a search for a date, and you end up with lists like that.
You can make all sorts of arguments for using what is, to most people, a cryptic format useful for sorting data files into order, but not for imparting information to humans -- which is the ultimate goal here. I see no reason to make an estimated 70% of my visitors confused as to when an event is planned to take place simply because W3C standards are more important to me than getting my message across simply and effectively.
I get hits from people doing Google searches like "How do I order valium online?" and "Where can I find a hotel in Berlin?" People who can't tell the difference between Google and Ask Jeeves are not going to want to spend time puzzling over weird dates.
You see, the reason the W3C, in its infinite wisdom, decided that YYYY-MM-DD is to be the only correct format allowed (if indeed that's what the W3C really meant by that) is because they are technically-minded people used to working with data which has to be presented in machine-readable format. YYYY-MM-DD is machine-readable. I need human-readable dates. The W3C are not always correct, and this is one instance where I feel they've got it wrong.
They've made the classic error of assuming everyone thinks like computer technicians. I design websites. I need to think like vicars, housewives and schoolteachers.
I did say "most" European languages. But you spelt the Italian wrong: it's iuglio, and I and J are actually variants of the same letter (and the G is silent but just makes the L sound "liquid"). Even Russian has iul' (although written in Cyrillic).
I'm happy to use (and do use) ISO8601 to augment/supplement my pages. But I need to use local date formats (see earlier post) because that is what the audience I am talking to expect to see. That may, of course, change over time.
One reason not to adopt it is the outrageous charges ISO make for copies of the standard: 104 Swiss Franks! That's -- what? -- nearly USD70.
They could teach a few seach engines a lesson or two about gouging the hand that feeds them.
Web sites don't have to contain any words, they might only contain numerical or graphical data, or images, the date of which is important.
Thanks. And I'd already found various previous drafts on the web, including your website which has two.
Surely safer though to wait until I can afford a copy of the final release. Follow draft standards is not really an ISO9000 recommendation. :)