[uf-discuss] human readable date parsing
zen at zenpsycho.com
Fri May 4 01:29:54 PDT 2007
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
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
More information about the microformats-discuss