[uf-discuss] Human and machine readable data format

Belov, Charles Charles.Belov at sfmta.com
Mon Jul 14 17:25:50 PDT 2008

See below.  

Hope this helps,
Charles Belov 
SFMTA Webmaster
> ------------------------------
> Message: 4
> Date: Tue, 15 Jul 2008 00:36:07 +1000
> From: Michael <mdagn at spraci.com>
> Subject: Re: [uf-discuss] Human and machine readable data format
> To: Microformats Discuss <microformats-discuss at microformats.org>
> Message-ID: <487B6457.1020609 at spraci.com>
> 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
> yyyy-mm-dd would certainly not be as scary for humans as a full
> 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 <mail at tobyinkster.co.uk>
> Subject: [uf-discuss] Human and machine readable data format
> To: microformats-discuss at microformats.org
> Message-ID: <FA54BB6C-2AD6-49E8-93C0-2792E407B17F at tobyinkster.co.uk>
> 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

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

More information about the microformats-discuss mailing list