[uf-discuss] Human and machine readable data format

[Belov, Charles]

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
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 <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
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.)