[uf-discuss] human readable date parsing

[Al Gilman]

At 3:10 AM +0100 4 05 2007, Patrick H. Lauke wrote:
>Al Gilman wrote:
>
>>If the machineable info is not routinely passing through the
>>consciousness of the communicating principals (that is, people),
>
>Who may, without the machine-mediated interpretation, not actually 
>be able to make a qualitative judgement (e.g. if I see a geo 
>lat/long value , I'm not enough of a walking map to instantly be 
>able to review that data...so I will need to run it through 
>something like google maps to work out if the data is duff or not)...
>
>>If in some community of communication, the data is routinely
>>extracted into view often enough so that bad data tend to get weeded
>>out, then the storage or transmission form doesn't have to be
>>directly comprehensible by people. But one of the virtues of markup
>>languages is just how much of the info is directly under the quality
>>control of people; expressed in as little-encoded form as can be
>>gotten away with.
>
>But to bring it back to the original argument, the routine 
>extraction does not necessarily have to equate to data visible in, 
>say, a tooltip. The routine extraction may well be mediated via some 
>machine interpretation.

I would agree with that.   I meant to be granting that, with the proviso
that the data were somewhere where it does get routinely processed
and displayed in the friendly format.  Email headers, for purposes
of argument, could be said to meet that requirement.  Microformat
@title values arguably can't be claimed to have that community of
processing support.  Even if there's an available library function to
do it, how many of the *readers* of such microformatted data will have
installed it?

The posterkid for your argument is indeed World Time.

Can't compare date+time around the world without specifying date+time+TimeZone.

Nobody understands UTC times.

Few can compare date_time around the world without machine assistance,
but if you give the machine the TimeZone that's a piece of cake and
routinely available (e.g. in display settings in your email reader).

<finally reading thread/>

<quote
cite="http://microformats.org/discuss/mail/microformats-discuss/2007-May/009528.html">

    July 26th, 2005

<span class="vmonth">July</span> <span class="vday">26</span>th, 
<span class="vyear">2005</span>

</quote>

Could the i18n pain, here, be mitigated by a dose of uFmt in the form of

<span class="vmonth" title="07">July</span>
<span class="vday">26</span>th, 
<span class="vyear">2005</span>

This is using Arabic numerals for the Gregorian calendar. Doesn't
deal with Moslem or Hebrew calendars, or calendars from other
cultures. But Arabic numerals are, for better or worse, pretty
international in their understandability. (And, I think, less
culturally invidious in that regard.) And something like this allows
the main-line display in line with what the author intends as regards
presentation.

This way, there doesn't have to be a collection of all the localised
month-names.  The author could have an author tool that knows
the mapping in their culture and inserts or checks the less-visible
data.  The Arabic numeral form is understood widely enough to
provide some community checking.

Al




>P
>--
>Patrick H. Lauke
>______________________________________________________________
>re·dux (adj.): brought back; returned. used postpositively
>[latin : re-, re- + dux, leader; see duke.]
>www.splintered.co.uk | www.photographia.co.uk
>http://redux.deviantart.com
>______________________________________________________________
>Co-lead, Web Standards Project (WaSP) Accessibility Task Force
>http://webstandards.org/
>______________________________________________________________
>Take it to the streets ... join the WaSP Street Team
>http://streetteam.webstandards.org/
>______________________________________________________________
>_______________________________________________
>microformats-discuss mailing list
>microformats-discuss at microformats.org
>http://microformats.org/mailman/listinfo/microformats-discuss