| This 86 message thread spans 3 pages: < < 86 ( 1 2  ) || |
|What Date Format do YOU use on YOUR website?|
| 7:39 pm on Jul 3, 2002 (gmt 0)|
Are you a 07-03-02 or 03-07-02 person, or does 03 July '02 or July 03, '02 do it for you?
Have a look at:
[edited by: engine at 7:53 pm (utc) on May 11, 2005]
[edit reason] trailing slash added [/edit]
| 1:46 pm on Jul 14, 2002 (gmt 0)|
The confusion about GMT is many fold. In the summer time, all clocks in Britain do not display GMT, they show a time that is one hour ahead of 'GMT', called British Summer Time. The confusion is that some people outside of Britain know what their own time zone is, and then try to calculate from the time on a British Clock. In summer they may end up with an answer that is incorrect by one hour, because they assumed that British clocks being in Britain would always display GMT. I have seen various web pages that attempt to show the 'time in GMT' but are showing a time that is an hour wrong.
It used to be that GMT was the 'base time zone' and all others worldwide were reckoned from it. In winter UK clocks do show 'GMT'. In summer they show 'GMT+0100' . The 'base time zone' is now UTC, and is not based on a geographical location.
I don't have a problem with people using the term 'GMT' solely as the British Winter Time time zone, and BST as the UK Summer Time Zone, but please note that GMT = UTC+0000 and BST = UTC+0100 . Similarly, the local time in New York is UTC-0500 in Winter and UTC-0400 in Summer due to the effects of Daylight Savings Time. Time Zones should be reckoned as to their offset from UTC.
> 2002-07-03 19:03:05 UTC-0700 should be:
> 2002-07-03T19:03:05-07:00 or:
If you are sending a DateTime to a machine then I heartily agree, however ISO 8601 is designed to be human readable. Where text is designed to be read by people, there really is no harm in stating separate date and time elements.
That is another form allowed by the standard. I would NOT advocate this for human reading, but it would be useful in the filenames of log files and so on.
>> 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. <<
The first steps have already been taken. In an earlier message I listed just a few places that have already adopted ISO 8601 as an official national standard. It covers at least 75 % of world population.
>> 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. <<
Think of a date sometime in the last few years. Write it in the YYYY-MM-DD format, then search for it at [google.com...] . You'll see it returned in at least a quarter of the results. This was true for the ten different dates I tried.
I see that various Professional bodies such as IEEE and Chartered Surveyors and so on have already made a commitment to 'go metric' in the US. It does appear to be happening. Looking for the site I found that on (probably usma.org).
[edited by: g1smd at 2:20 pm (utc) on July 14, 2002]
| 2:19 pm on Jul 14, 2002 (gmt 0)|
IEEE and Chartered Surveyors are both narrow professional fields. After a couple of hundred years, the vast majority of the US population are still glowingly unacquainted with metric.
UTC is based on geographical location. All time zones are based on geographical location. It is simply the name that has no geographical reference; but UTC is, basically, the time of day at 0° longtitude.
As for Google searches: compare a search for '24 January 2000' [google.com] with a search for '2002-01-24' [google.com].
Now imagine I am German. I speak no English. Which is more helpful to me: the results for 2000-01-24, or the results for 24 Januar 2002 [google.com]?
Of course the date I typed in is returned in SE results. It's supposed to, that's what a search engine is programmed to do.
| 2:41 pm on Jul 14, 2002 (gmt 0)|
> Now imagine I am German. I speak no English. Which is more helpful to me: the results for 2000-01-24, or the results for 24 Januar 2002?
NO. That is what 'Language="DE"' is for in Meta tags. By your argument searching for 'September' will miss all pages that only have 'Sep' or 'Sept'
> Of course the date I typed in is returned in SE results. It's supposed to, that's what a search engine is programmed to do.
You said, earlier, that the ISO format isn't used anywhere. My point was that if you use it as a search string, then you will see that it is already used in a very large number of places. Just because you haven't yet seen it, doesn't mean to say that it hasn't happened. It has.
> IEEE and Chartered Surveyors are both narrow professional fields.
These are just two that I could remember, there are many others. However, if all building work has to be drawn up in metric then anyone who works in the building trade is now exposed to this usage. That is a very large number of people. Likewise for all the other 'narrow' topics. Alltogether they all add up to a lot of people.
| 6:59 am on Jul 15, 2002 (gmt 0)|
Two search results from Google Deutschland:
German pages containing 2002-01-24 [google.de] (approx 12,300 results)
German pages containing 24 Januar 2002 [google.de] (approx 496,000 results)
Few people outside of SE Asia think year-month-day. Few people will use that format in search engine enquiries. And you won't force them to, either. This is a simple fact of life which you, the webmaster, must cater for. You must think like your intended visitors, otherwise you will lose them.
You are advocating ISO on principle without thinking about your audience. (Actually, you are advocating part of the ISO specs; you're quite happy to abandon it when it comes to adding the time of day, for instance -- this is inconsistent, but that's not the point.) Few other things in life are standardized, why should dates be?
Do builders in the US really use the metric system? I'm not entirely convinced they do, but anyway that's still not a huge number of people and I can guarantee that they do not use the metric system in their everyday lives. Publish a recipe which calls for 300g flour and 25g butter, and Americans will be taking out their calculators (or trying a different site). So will a lot of Brits, actually, despite the fact that pounds and ounces are almost illegal.
Go the extra mile. Think of your audience. Using ISO dates will not affect your page rankings because so few people actually use that date format in search engine enquiries, except perhaps a few purist webmasters and scientists (and Koreans). Just a few extra keystrokes and you could make life so much easier for Mr and Ms Average-Surfer, and in most cases it's them you are catering for.
I can guarantee that Mr Average-Surfer will type a date like "16 March" into a Google search; and I can also guarantee that Frau Durchschnitts-Surferin will type "16 März" or, possibly, "16 Maerz". We are not going to change that, and if it makes life more difficult for us, well, that's why we charge so much for designing websites.
| 11:44 am on Jul 15, 2002 (gmt 0)|
I just got to casually wondering what format ISO themselves use in the human-readable parts of their webpages.
First date I found is on the home page: http://www.iso.ch/iso/en/ISOOnline.frontpage
at it reads: 23-28 September 2002, ISO 25e General Assembly in Stockholm
Well, to be a standard, maybe we should all do what they are doing. :)
| 3:06 pm on Jul 15, 2002 (gmt 0)|
|The confusion is that some people outside of Britain know what their own time zone is, and then try to calculate from the time on a British Clock. In summer they may end up with an answer that is incorrect by one hour, because they assumed that British clocks being in Britain would always display GMT. |
Drat! (Guilty as charged.)
But how much problem does this lack of information really cause? At most, my guessing will have me off by an hour, right? Since I'm not doing rocket science, I guess that's not a problem. And for those actually doing the rocket science, they probably know this fact.
| 3:31 pm on Jul 15, 2002 (gmt 0)|
Following hawkgirl's lead, I thought I'd check the date format used by the rocket scientists themselves.
This is NASA's Worldwide Space Launches 2002 page: http://www.hq.nasa.gov/osf/2002/launch02.html
And the very first launch of the year was on Jan. 16
This is details of the Mars 2001 launch from page: http://sse.jpl.nasa.gov/missions/mars_missns/mars-mod.html Launch Date: 07-Apr-2001 (11:02 EDT)
If international orgs like ISO and interplanetary ones like NASA don't use ISO8601 there must be a reason. :)
| 3:52 pm on Jul 15, 2002 (gmt 0)|
I'm about this far (--) from changing back to my previous readable format. There is enough documentation in this thread to support both sides. But, for readability, I think the non ISO supporters have the floor. ;)
| 4:19 pm on Jul 15, 2002 (gmt 0)|
Virtual home of George W. (www.whitehouse.gov ;))
"Today at the White House, Jul. 15, 2002."
Tony Blair online (www.number-10.gov.uk - but doesn't Tony actually live at number 11??)
"15 July 2002"
Indian Parliament's most recent press release (http://alfa.nic.in/) listed as:
"JULY 12, 2002"
Japan's news about their Prime Minister (http://www.kantei.go.jp/foreign/index-e.html):
"July 8, 2002"
| 4:31 pm on Jul 15, 2002 (gmt 0)|
Okay, so now I'm about this far (-).
Each time g1smd posts a rebuttal, I end up adding another (--) to my distance meter. ;)
| 6:44 pm on Jul 15, 2002 (gmt 0)|
Some bits of NASA have changed over, some have not. NASA internal standards call for YYYY-MM-DD (see CCSDS.GOV or similar). They are making the change only as new systems are introduced. One part already done is: [umbra.nascom.nasa.gov...] and [umbra.nascom.nasa.gov...] with a mix of 2002 July 20 and 2002-07-20 . Another part that has adopted YYYY/MM/DD (rather than YYYY-MM-DD) is [sohonascom.nasa.gov...] .
If nothing else, have I at least convinced everyone here to remove all dates like 03-02-01 and 03-02-2001 off their pages, replacing them with something else ?
I'd prefer 2002-07-01 or 2002 July 01, but if you want 01 July 2002 or July 01, 2002 then these are at least readable by English speaking people whereas 01-02-03 will always be misunderstood by many readers.
You'll see more German websites adopting YYYY-MM-DD as time goes on, as in 1996 the DIN 5008 standard for typographical rules in documents replaced 20 VII 2002 formats with 2002-07-20 formats. This is gaining ground, but like metric will take a generation to achieve.
ISO use of the format is varied. It is used on all official documents, and in parts of their website, however not all yet.
| 9:30 pm on Jul 15, 2002 (gmt 0)|
Well, I've never used digits for months, for the very reason that it's ambiguous when the date is in the range 1-31.
|You'll see more German websites adopting YYYY-MM-DD as time goes on, as in 1996 the DIN 5008 standard for typographical rules in documents replaced 20 VII 2002 formats with 2002-07-20 formats. This is gaining ground, but like metric will take a generation to achieve. |
The 20 VII 2002 format is only used for official government documents. The general populace has only ever used the format 20.07.02 (sometimes 20-07-02), or written it out in full, totally ignoring any official DIN standards. The changeover to 2002-07-20 will only affect those people who were using official standards anyway, which is to say: hardly anyone.
Even in official business correspondence, it is usual to write "Samstag, den 20. Juli 2002".
| 12:12 am on Jul 16, 2002 (gmt 0)|
|If international orgs like ISO and interplanetary ones like NASA don't use ISO8601 there must be a reason. |
The reason could be ignorance of standards on the part of the individuals who build those pages.
| 8:05 am on Jul 16, 2002 (gmt 0)|
I've had a quick look at some of the NASA pages linked to, and come to the following conclusions:
YYYY-MM-DD format is used, for example, on the timestamps on the images themselves (almost in ISO format, but not quite, dammit), because those dates are meant for members of the scientific community (one of the narrow fields where members have agreed to use the ISO format).
A strange format (e.g. 2002 June 9) is used on, for example, umbra.nascom.nasa.gov, which is a page designed for (I guess) amateur astronomers. Note the lack of design and the use of much technical jargon ("With the activation of the CELIAS CTOF sensor, all SOHO isntruments are operating as they were before the thermal reconfiguration and emergency Sun reacquisition (ESR) of 2002 February 5") -- this suggests that this is for people who understand the basics of astronomy and probably (but not necessarily) familiar with ISO. But the webmaster clearly has tried to cater for those who aren't by writing the month in full.
Compare this to the page on the Mars Mission. The design of the page (a bit too much, if you ask me) and the much simpler, explanatory language ("Using a process called aerobraking, the spacecraft skimmed the surface of the Martian atmosphere 332 times over nearly three months to slow down instead of firing its thrusters") suggests that this is a site for people who don't know the technical stuff and just want to know if NASA has found evidence of bug-eyed green monsters, or whether one day we might be living on Mars. For that reason you will find the dates in a format more familiar to laymen.
Interestingly for a site by a US government organization, the dates are in date-month-year format.
NASA have basically tailored the way they present dates according to their audience, viz:
2002-03-05 for members of the scientific community
2002 March 05 for amateur astronomers
5-Mar-2002 (or other more verbose formats) for everybody else
| 5:53 pm on Jul 17, 2002 (gmt 0)|
The usability standards recommend the following format:
July 17, 2002
If you include the day of the week (I do), spell it out, as follows:
Wednesday, July 17, 2002
If you include time, include the time zone, as follows:
10:46 PM PDT
Use the commonly recognized AM/PM or a.m./p.m. or A.M./P.M.
However, usability standards recommend time be EXcluded unless the content is time sensitive, such as stock quotes or news articles added/updated several times a day.
| 11:59 pm on Jul 17, 2002 (gmt 0)|
|If you include time, include the time zone, as follows: |
10:46 PM PDT
As mentioned before, using the 3-letter time zone codes is ambiguous. Can anybody name a city in the EST time zone? Correct answers include New York and Sydney, which are on opposite sides of the planet. While I realise that most of the general public aren't yet familiar with UTC, at least it's unambiguous, and the more we use it the quicker people will get used to it. I only needed to see UTC a couple of times before I felt comfortable with it :)
| 8:48 am on Jul 18, 2002 (gmt 0)|
It depends on the audience to a large extent. If you're targetting a world-wide audience, you might want to use UTC. If you're targetting a more local audience, using abbreviations might be appropriate. Time zones are tricky, and a surprising number of people find it nearly impossible to grasp the concept. Add the International Date Line into the mix, and many people just give up. There's little you can do about that: it's just that time zones are complicated.
If I'm advertizing local events, I might put a note on the page "All times in Central European Time", or "All times in local time", since even if you're travelling to the event from a different time zone, you would set your watch to local time anyhow.
Be careful with Usability Standards, and bear in mind that the ones quoted above apply to English language websites. Many non-English speaking countries in Europe use the 24-hour clock, so times on a German website (for example) should always be in 24-hour format.
| 9:49 pm on Jul 18, 2002 (gmt 0)|
Using one time zone for sites throughout the world is an excellent idea. My question is, since I don't have the time to read six pages to find that info, what does UTC stand for? Is this the same as GMT?
| 10:16 pm on Jul 18, 2002 (gmt 0)|
UTC is Universal Time, Coordinated and comes from 'Atomic Clocks', and is one of a series of UT time-scales. For the layman it is equivalent to GMT. The term GMT was made obsolete in 1971.
Note that the old GMT (now UTC) is used in Britain only in the Winter, in summer BST (one hour ahead) is used on clocks.
A search on Google (or other major search engine) will find hundreds of places with more info.
For Time Zones, nothing can really beat an indication like -0500 or +0900 for clarity.
> The usability standards recommend the following format:
> July 17, 2002
Hmm, Month-Day-Year, sounds like an American recommendation, Europeans would have recommended Day-Month-Year:
17 July 2002 which does away with the comma.
| 10:31 pm on Jul 18, 2002 (gmt 0)|
I'll tell you what, there are some real strong points being made from all parties. I'm about ready to make some slight modifications to my date and time stamps and have learned way too much about time since this thread started.
g1smd, you sure know how to come back with a very convincing reply to all the rebuttals. I like these kinds of threads. Good solid discussions centered around appealing to a global audience.
| 6:24 pm on Jul 19, 2002 (gmt 0)|
In another thread on webmasterworld.com someone said:
> Just added the URI and hadn't even had a chance to view in Opera when I saw a problem in Moz. I'm using...
> Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020530
Looks like a software release date in the last eight characters of the last line above.
| 6:38 pm on Jul 19, 2002 (gmt 0)|
> Looks like a software release date in the last eight characters of the last line above.
Good catch! I saw that but didn't think too much of it now that I'm a convert.
My WebTrendsLive stats also gives me three date options...
Of course I'm using option #3. ;)
| 8:31 pm on Jul 19, 2002 (gmt 0)|
Ok, for clarification on my generalizations, here's the verbatim wording of the recommendations made by Jakob Nielsen in his book "Website Usability: 50 Websites Deconstructed." Under the topic Dates and Times:
105. Show dates and time for time-sensitive information only, such as news items, live chats, stock quotes, and so forth.
106. Show users the time that content was last updated, not the computer-generated current time.
107. Include the time zone you are using whenever you reference a time.
108. Use standard abbreviations, such as p.m. or P.M.
109. Spell out the month or use month abbreviations not numbers.
Quote: "Hmm, Month-Day-Year, sounds like an American recommendation, Europeans would have recommended Day-Month-Year"
Now, excuse me, but my first reaction to that statement was negative. You will be happy to see that I managed to restrain my response to that negativity.
Instead, I re-reviewed my notes and other standards sites. W3C is the primary recognized standard. Their standard can be found here:
Following a link to the ISO-8601 standard on dates and times, one finds the following:
"The international standard date notation is
where YYYY is the year in the usual Gregorian calendar, MM is the month of the year between 01 (January) and 12 (December), and DD is the day of the month between 01 and 31."
So, in essence, you and I are Both wrong. And I will yield to the international standard, in the interests of internet usability for all.
| 11:59 am on Jul 21, 2002 (gmt 0)|
Well, that brings us back to square one. That was the start of the whole argument: I maintain that just because the W3C have decided to use a date format that is unfamiliar to the vast majority of surfers doesn't mean that they're right to do so. The counter argument is that the ISO specs are non-language specific and therefore more accessible to a global audience, even if they have to stop and think for a while.
I prefer to use whichever format is appropriate for my intended audience. Very occasionally, that might be YYYY-MM-DD, but more usually it will vary. However, I always, always spell the month out in full to avoid ambiguity. When I write in English I use the 12-hour clock, when I write in German I use the 24-hour clock. And so on. For me, it's not about adhering to standards which have been arbitrarily applied, it's about making sure my audiences understand me.
| 7:59 pm on Jul 26, 2002 (gmt 0)|
It's not just ISO and W3C supporting YYYY-MM-DD, now the IETF support it:
From the RFC list yesterday. Amongst other things, proposes an ISO 8601 profile for use in future Internet protocols.
A new Request for Comments is now available in online RFC libraries.
Title: Date and Time on the Internet: Timestamps
Author(s): G. Klyne, C. Newman
Status: Standards Track
Date: July 2002
Mailbox: GK@ACM.ORG, firstname.lastname@example.org
I-D Tag: draft-ietf-impp-datetime-05.txt
This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
This document is a product of the Instant Messaging and Presence Protocol Working Group of the IETF.
This is now a Proposed Standard Protocol.
This work was originally proposed way back in 1997 and Chris Newman has put a lot of effort into this, with many refinements along the way. Looks like YYYY-MM-DD is here to stay. RFC 3339.
Yes I *KNOW* it is an RFC for *Protocols* but yet another example of high-level adoption.
| 8:39 pm on Jul 26, 2002 (gmt 0)|
You know, this is slightly getting on my nerves. As you yourself point out, this is for protocols -- machine-readable stuff.
It really is silly. Technicians use a certain date format for certain things and you draw the conclusion from that that soon we'll all be using this format?
Using that logic, we should all be putting NaCl on our food.
| This 86 message thread spans 3 pages: < < 86 ( 1 2  ) |