[uf-discuss] human readable date parsing

[Breton Slivka]

On 05/05/2007, at 3:29 AM, Andy Mabbett wrote:

> In message <0DEB8416-55C4-4AB8-8126-B3ABA071EC66 at zenpsycho.com>,  
> Breton
> Slivka <zen at zenpsycho.com> writes
>
>> It seems to me that in order  to more effectively solve this problem,
>> this set of restrictions  should be clarified- Here's what I've  
>> got so
>> far, correct me if I'm  wrong.
>>
>>
>> Date markup must:
>>
>> 1> be capable of marking up dates from multiple cultures and  
>> languages
>> 2> Follow the DRY principle
>> 3> Be completely visible
>> 4> Follow common usage
>> 5> Be machine readable
>> 6> Be unambiguous
>>
>> and the unstated (and perhaps unconcious) restriction
>>
>> 7> Be as similar to iCalendar as possible in form and function.

>    8>  Meet WCAG accessibility guidelines
>

Right, rereading the thread, I just noticed that. Thanks.


Here are some other possibilities for internationalization.

Date legend: Define the date format in use at the beginning of the  
vcalendar or vevent, using MM-DD-YY style format, or some other  
suitable format definition style. This would accomodate a wide  
variety of formats, but still exclude non gregorian calendars.

Database of date formats in parser: Someone mentioned this, and  
didn't seem to make an argument as to why it would be a bad idea  
aside from a vague fear of complexity. Navigating a list of month  
names shouldn't be a problem, because I expect most people to know  
how to spell the names of months in their own language without  
needing a dictionary. I don't see anything wrong with complexity in  
the parser if it solves real problems for the publisher. That's what  
microformats are all about, right? If someone is publishing in a  
chinese calendar format, with ISO dates attached, in what way is the  
semi visibility of the ISO date going to ensure its accuracy in that  
situation? They don't resemble eachother! It seems to me that the ISO  
format fails both internationalization, and accessiblity. (and that  
is what this thread is all about!) let's redirect the (neccesary)  
failure to a less important restriction.

Let's not forget Al Gilman's modification to my original solution:  
Break up the different parts of the date, and add a machine readable  
title  to each part . This is best of both worlds, as the other can  
format the date in whatever way is sensible, and since the titles are  
seperated into different markup, it may read better in a screen  
reader.  (Zero seven July twenty six two thousand five), and doesn't  
require a database.

80% solution?