- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 18 Nov 2011 20:40:33 +0000 (UTC)
- To: "Kang-Hao (Kenny) Lu" <kennyluck@csail.mit.edu>
- cc: W3C Public Archive <www-archive@w3.org>
On Fri, 18 Nov 2011, Kang-Hao (Kenny) Lu wrote: > > * As a non-native English speaker, I find "h" for hours, "m" for minutes > and so on a bit unfamiliar. I would prefer a way that allows the more > common [hh]:[mm]:[ss] practice. The ISO 8601 "PT[hh]:[mm]:[ss]" seems > odd too so I guess another attribute for duration as stated on [1] would > work for me, although I can't guarantee if spelling "duration" is > actually easier than using "m" and "s". > > Anyway, a string like "3m20s" doesn't show up in real world UI and > "3:20" is obviously more common. > > [1] http://wiki.whatwg.org/wiki/Time_element#duration I considered this, but it turns out to introduce ambiguities with actual time formats, e.g.: <time>12:10</time> ...could be the middle of the day, or a 12 minute song, or a 12 hour period, it's hard to say. > * For the majority of use cases there will be less than 4 components and > I don't think "1h20m10s" is any less readable than "1h 20m 10s", and > "3m20s" looks better to me than "3m 20s". Therefore, I am against > intervening spaces. They don't seem to cause any harm, and some people like them, so I went with allowing them. > * I am against non-single-letter abbreviations. I don't want to have > trouble thinking which one of "hours" and "hour" is right. Agreed. > * I would prefer the following heuristic for "month" and "minutes" > disambiguation (for non ISO 8601 string only): > 1. For a "m", If there's a "y" before it or there's a "w", "d", "h" or > another "m" after it. Then "m" is for "month" (so you can do "1y3m" or > "1m10d") > 2. Otherwise "m" is for "minutes" > (I heard the rumor that Microsoft uses "M" for month and "m" for > minutes, so I guess this needs some input from them) I went with not allowing months at all, which simplies this rather. > * I don't yet see the value of conformance-parsing mismatch here and I > don't know who'll implement "parse a duration string" either. I'll mark > non-conforming duration string as having no meaning for now. The value is avoiding having to have two parsers (one for the each of the two duration syntaxes). Cheers, -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 18 November 2011 20:41:03 UTC