See below. Hope this helps, Charles Belov SFMTA Webmaster > > ------------------------------ > > Message: 4 > Date: Tue, 15 Jul 2008 00:36:07 +1000 > From: Michael <[EMAIL PROTECTED]> > Subject: Re: [uf-discuss] Human and machine readable data format > To: Microformats Discuss <microformats-discuss@microformats.org> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > >> > > actually the suggestion of splitting the datetime into date, time and > timezone marked up in separate elements seems to me like a good compromise. > > yyyy-mm-dd would certainly not be as scary for humans as a full datetime > with timezone
It would still not be pleasant. Month, day, year, hour, minute, second, time zone, and optional am/pm could all be split up, removing ambiguity. > ------------------------------ > > Message: 6 > Date: Mon, 14 Jul 2008 21:54:57 +0100 > From: Toby A Inkster <[EMAIL PROTECTED]> > Subject: [uf-discuss] Human and machine readable data format > To: microformats-discuss@microformats.org > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > Scott Reynen wrote: > >> I'm assuming by "different calendar," you mean non-Gregorian? If so, >> what are the use cases for non-Gregorian dates in hCalendar? > > It's not so much the case of wanting to encode non-Gregorian dates in > hCalendar, but wanting to include non-Gregorian dates on the web page. > > <abbr class="dtstart" title="2008-07-14">11 Rajab 1429</abbr> > > Is '2008-07-14' to be considered an appropriate expansion of the > "abbreviation" '11 Rajab 1429'? > > In case anyone is wondering whether non-Gregorian calendars are used > in practice, the Islamic calendar (used in the example above) is the > official calendar for Saudi Arabia, and used in religious contexts in > many other countries; the Julian calendar is still used in religious > contexts by Orthodox Christian churches, and frequently used by > historians to refer to many older dates; the Chinese calendar is used > for various religious and cultural reasons not just in China, but in > some other Asian countries, but not for any official purposes. > I would cite specific pages that use these calendars, but I don't > speak Arabic, Russian or Mandarin, so don't know the correct terms to > Google for. > So there will be cases where people want to publish non-Gregorian > dates, but for interoperability with iCalendar, they'll need to > include a machine-readable Gregorian equivalent date. This is an > example of where you're going to have very significant differences > between the human and machine-readable representations of the same > dates. Well, gee, if an Arabic screen reading program read out a Gregorian date where the author was expecting an Arabic date to be read, that could be pretty insulting. In any case, you seem to be assuming a human entering a non-Gregorian date (or, for that matter, a Gregorian date) can accurately transform the human-readable date into a machine-readable date. I can tell you right now that I personally am 24-hour-calendar challenged. I usually get the 12-to-24 hour conversion right, or vice versa, but now and then... And I wouldn't want a screen reader to read the time to me using the 24-hour clock on a U.S. website. I believe machines can do this translation more reliably than humans, provided they are asked to do so. In any case, there could be a parameter for alternate calendar. > (It's also interesting to note that automatic translation from the > Islamic calendar to Gregorian is impossible to perform reliably, as > it is based on human observation of the movements of the sun and > moon, not on the actual -- predictable -- movements of the sun and > the moon. Thus the exact numbering of dates is not usually known very > far in advance.) > Then it seems there would be no way to provide a reliable ISO date for non-impending events; therefore, requiring ISO for the hCalendar record would prevent use of hCalendar for that event. (For that matter, you would need latitude and longitude to eventually resolve the date and time.) _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
