[uf-discuss] human readable date parsing

[Breton Slivka]

And yet, to not do so means breaking another restriction. It's about  
give and take. Is it better to make it easier for publishers, and  
harder for parsers, or is it better to store the same date twice, and  
let one go out of sync?

Another solution is to just store ISO dates free and clear, and offer  
a javascript library to parse it into a variety of common/ 
international date formats. My basic point is, that it is impossible  
to satisfy all the restrictions with one format. Perhaps it is better  
to have several ways to mark it up, depending on the situation. Which  
restriction is it important to NOT break for a particular situation?




On 04/05/2007, at 12:42 PM, Michael MD wrote:

>> I don't think this will work, for the same reason tel-type and  
>> adr- type don't work: l10n/i18n. They require displayed machine  
>> values to  be in English.
>>
>> <span class="vmonth" lang="en">July</span>
>> <span class="vmonth" lang="es">julio</span>
>> <span class="vmonth" lang="jp">7 月</span>
>> <span class="vmonth" lang="ru">июль</span>
>
> good point ...
>
> parsing it might end up needing a database of day and month names  
> and character sets and numbers in every known language!
> (possibly also other types of calendars that might be used in some  
> parts of the world ... this could get very complicated very quickly!)
>
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss at microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss