RE: ISO 8601 assumption
I even disagree about the assumption that yyyy-mm-dd is unambigous, because if the month number and the day-in-month number can be confused, they surely will according to Murphy's law, e.g. some people will create yyyy-dd-mm dates just as surely as they will create mm-dd-yyyy dates. I have always liked another standard, the yyyy-mmm-dd standard, because no matter how you interchange the elements, they are always unambigous, e.g. 08-OCT-2000, AUG-10-2000 or even 2000-01-JAN can't be misinterpreted simply because each element has different length. Unfortunately this standard has not gained much recognition, perhaps because it assumes english as the base language for the acronyms (JAN, FEB, MAR ...). That humanity has still not come up with a completely unambigous date format which is generally accepted, really shows how much IT is still in it's infancy. From a technical point of view it is a trivial problem, but of course it should be human-readable. Another similar problem is the myriad of ambigous ways that we identify a computer user, without really getting certain WHO it is. I am talking about those 40+ different account names with corresponding password I'm keeping in a password keeper program, about all the different finger print, eye scanner systems etc. that have been developed isolated, still without reaching a simple way to identify a computer user. Maybe in 20 years I will laugh of this mail because the solution has been implemented everywhere, but at the moment I think it is a big problem that is the real reason why e-commerce is still not raving off with millions of computer based transacions. Who are you giving credit? The 5-year old son of a well-known user? You'll have to guess. Meanwhile, why yyyy-mmm-dd or some other completely unambigous date format could not become international standard is beyond me. We *could* begin by defining an unambigous standard for the tzdata list though. I realize of course that isolated seen tzdata is already unambigous because it is already stated *somewhere* which standard has been used. My apologies for drifting a bit away from the original issue. Jesper Nørgaard Email: jnorgard@Prodigy.Net.mx Programador/Analista CIMMYT - Centro Internacional de Mejoramiento de Maíz y Trigo Dirección: CIMMYT, Lisboa 27, 06600 Mexico, D.F. Tel.: +52 (5) 58-04-20-04 ext. 1374 Fax: +52 (5) 58-04-75-58 Tel. Casa: 53-10-05-95 ó 53-10-97-78 CIMMYT home page: http://cimmyt.cgiar.org Check out my Time Zone Converter: http://timezone50.homepage.com ---------- From: Garrett Wollman[SMTP:wollman@khavrinen.lcs.mit.edu] Sent: Jueves 5 de Octubre de 2000 6.10 To: Alex LIVINGSTON Cc: Time Zone Caballeros Subject: Re: proposed tz changes for Paraguay, Brazil, Wayne County, etc. <<On Thu, 5 Oct 2000 18:47:32 +1100, Alex LIVINGSTON <alex@agsm.edu.au> said:
If hyphens are used to separate the numbers, the assumption is (I hope) that ISO-8601-style decreasing-magnitude notation is being used.
No, no such assumption can be made. Using hyphens to separate elements in a date was well-established practice in the United States before there ever was an ISO. The only time you can assume that a date is written in ISO 8601 format is when the full yyyy-mm-dd form is used. -GAWollman
On Fri, 06 Oct 2000 00:58:32 -0500, Jesper Nørgaard <jnorgard@Prodigy.Net.mx> wrote:
I even disagree about the assumption that yyyy-mm-dd is unambigous, because if the month number and the day-in-month number can be confused, they surely will according to Murphy's law, e.g. some people will create yyyy-dd-mm dates just as surely as they will create mm-dd-yyyy dates.
But the thing is: mm/dd/yy[yy] is in widespread use (US), as is dd/mm/yy[yy] (much of Europe, I'm told). [yy]yy-mm-dd was used in Japan even before the ISO standard came out. But no culture has ever used [yy]yy-dd-mm format, and there is absolutely nothing to recommend it, so there is no reason to expect anyone to adopt it. Yes, the perverse can use that format just to confound us, but in practice one can safely assume that a nnnn-nn-nn date is in yyyy-mm-dd format. As to an unambiguous format, there's always yyyy-jjj (e.g., today (2000-10-06) is 2000-280 --- the 280th day of AD 2000), but this has never caught on in the greater culture (and probably never will). --Ken Pizzini
At 07:40 +0000 2000-10-06, ken@halcyon.com wrote:
But the thing is: mm/dd/yy[yy] is in widespread use (US), as is dd/mm/yy[yy] (much of Europe, I'm told).
Slight refinement: dd/mm/[yy]yy. Used in all European countries - and all countries colonized by a European country at one time or another which haven't had a strong US influence since, and probably all remaining Asian, African, and Pacific countries - that don't use [yy]yy-mm-dd. mm/dd/yy[yy] is restricted almost entirely to the US and a few neighbors. I would hesitate to say it is in widespread use.
[yy]yy-mm-dd was used in Japan even before the ISO standard came out.
And in China, and in Sweden, and in Hungary, ... (possibly with different separators). Also in the Arab world, in the sense that the digits (all of them) appear in the same order from left to right, only Arabic is written right to left.
But no culture has ever used [yy]yy-dd-mm format, and there is absolutely nothing to recommend it, so there is no reason to expect anyone to adopt it. Yes, the perverse can use that format just to confound us, but in practice one can safely assume that a nnnn-nn-nn date is in yyyy-mm-dd format.
Thanks Ken. You've put it much better and more concisely than I could have. --Alex _______________ Alex LIVINGSTON Macintosh and Lotus Notes Support / Information Technology (IT) Australian Graduate School of Management (AGSM) UNSW SYDNEY NSW 2052 / Australia Facsimile: +61 2 9931-9349 / Telephone: +61 2 9931-9264 Time : UTC+11---[last Mar. Sun.---UTC+10---[last Aug. Sun.---UTC+11--- At end of today, Wednesday, October 18, time since epoch (1-1-1 at 00:00:00) = 730411 days = 1999.79739488 average Gregorian years time until 3rd millennium, 21st century, 201st decade, 2001st year = 74 days = .20260512 average Gregorian years
We could re-number the months 32 to 43, instead of 1 to 12. Today's date could be written 5-41-2000 or even 5/2000/41 etc. ;) But seriously...How about preceding the month number with the letter 'M'? Today could be 5:M10:2000. BTW - I always feel that a dash used in conjunction with a number is just asking to be confused with a minus or negative symbol. Ian Tragen ian@mirage-avm.com http://mirage-avm.com Jesper Nørgaard wrote:
I even disagree about the assumption that yyyy-mm-dd is unambigous, because if the month number and the day-in-month number can be confused, they surely will according to Murphy's law, e.g. some people will create yyyy-dd-mm dates just as surely as they will create mm-dd-yyyy dates.
(etc.)
Jesper Nørgaard wrote:
I even disagree about the assumption that yyyy-mm-dd is unambigous [...]
I have always liked another standard, the yyyy-mmm-dd standard, [...]
In French, June 6th in year 1944 was 1944-JUI-06, and July 6th was 1944-JUI-06... See the problem? (I even remember of a past version of a well-known spreadsheet program that stumbles on this one). Of course, these are in real use, so we have some systems to disambiguate: using four letters (but then May "mai" is a problem), or using "JUN" for "juin" and "JUL" for "juillet"), but this is a problem anyway. If you think on agreeing upon English is a solution, what about: - Russians (and a lot of other people) that needs to change the keyboard encoding to type a date in the middle of a run of Cyrillic text... - the non-English natives where the name of the months are *really* different ; - the non-English people that are *not* English enable.
That humanity has still not come up with a completely unambigous date format which is generally accepted, really shows how much IT is still in it's infancy.
Have a look toward the discussions of the next format for time expression (the one that will survive to 2038): it will show you that, indeed, things are still to evolve. Antoine
participants (5)
-
Alex LIVINGSTON -
Antoine Leca -
Jesper Nørgaard -
ken＠halcyon.com -
MiRaGe＠MiRaGe-avm.com