Re: [whatwg] Time Parsing
On Wed, 15 Jun 2011, Lachlan Hunt wrote: On 2011-06-15 07:55, Ian Hickson wrote: On Mon, 28 Mar 2011, Lachlan Hunt wrote: This should also only allow up to 3 digits representing milliseconds. If there are 4 or more digits (microseconds or beyond), the spec should state that the remaining digits should be truncated. Why? Because the Date object can only handle precision to 3 decimal places, and implementations interpret times like 00:59:59. as 00:59:59.999 instead of rounding it up to 01:00:00.000 Fair enough. Done. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Time Parsing
On Wed, 11 Jan 2012, Ian Hickson wrote: On Wed, 15 Jun 2011, Lachlan Hunt wrote: On 2011-06-15 07:55, Ian Hickson wrote: On Mon, 28 Mar 2011, Lachlan Hunt wrote: This should also only allow up to 3 digits representing milliseconds. If there are 4 or more digits (microseconds or beyond), the spec should state that the remaining digits should be truncated. Why? Because the Date object can only handle precision to 3 decimal places, and implementations interpret times like 00:59:59. as 00:59:59.999 instead of rounding it up to 01:00:00.000 Fair enough. Done. To elaborate, what I did was make it non-conforming, and define how to map fractional milliseconds to Date objects. I didn't actually make the parsing algorithm itself truncate the value, so theoretically if someone has non-conforming content with values with fractional milliseconds that is processed by software that isn't based on JS, it could still support those values. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Time Parsing
On 2011-06-15 07:55, Ian Hickson wrote: On Mon, 28 Mar 2011, Lachlan Hunt wrote: This should also only allow up to 3 digits representing milliseconds. If there are 4 or more digits (microseconds or beyond), the spec should state that the remaining digits should be truncated. Why? Because the Date object can only handle precision to 3 decimal places, and implementations interpret times like 00:59:59. as 00:59:59.999 instead of rounding it up to 01:00:00.000 -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Time Parsing
On Mon, 28 Mar 2011, Lachlan Hunt wrote: The algorithm to parse a time component contains a bug. When parsing the seconds, the spec states: Collect a sequence of characters that are either characters in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9) or U+002E FULL STOP characters. If the collected sequence has more than one U+002E FULL STOP characters, or if the last character in the sequence is a U+002E FULL STOP character, then fail. Otherwise, let the collected string be second instead of its previous value. This is incorrect because it allows the second component to contain more than 2 digits before the decimal point. i.e. 00:00:012.345 would parsed without error. Fixed. This should also only allow up to 3 digits representing milliseconds. If there are 4 or more digits (microseconds or beyond), the spec should state that the remaining digits should be truncated. Why? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Time Parsing
Hi, The algorithm to parse a time component contains a bug. When parsing the seconds, the spec states: Collect a sequence of characters that are either characters in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9) or U+002E FULL STOP characters. If the collected sequence has more than one U+002E FULL STOP characters, or if the last character in the sequence is a U+002E FULL STOP character, then fail. Otherwise, let the collected string be second instead of its previous value. This is incorrect because it allows the second component to contain more than 2 digits before the decimal point. i.e. 00:00:012.345 would parsed without error. The algorithm should instead state to look for 2 digits representing the seconds, then check if there's a decimal point, and then check for the fractional part of the second. This should also only allow up to 3 digits representing milliseconds. If there are 4 or more digits (microseconds or beyond), the spec should state that the remaining digits should be truncated. e.g. 00:00:00. Technically, that would be 999,900µs, but it needs to be rounded down to 999ms, not rounded up to 1s. http://whatwg.org/C#parse-a-time-component -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[whatwg] time parsing and rendering
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#parse-a-month-component Is there a use case for machine-readable dates after ? I'm sure HTML5 will have been obsoleted before it's meaningful to express accurate times that far in the future. As existing similar formats use a 4-digit year, adapting parsers for those is a lot easier if the HTML5 year format be exactly 4 figures. Also, it seems more likely that 4-digit years will be typos than intended and useful as machine-readable data. If there are no strong use cases for it, please make it only. http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#parse-a-date-or-time-string 10. If the date present and time present flags are both true, but position is beyond the end of input, then fail. This seems to be a bug if you consider how '2009-11-16T' would be parsed. The algorithm is supposed to return a date time or global date and time, but '2009-11-16T' is valid as neither. The intent of this step must be to make sure that T is always followed by a date, but it won't work. Except from being in the incorrect order (after time present may have been set to false) it also checks for the end of input, which doesn't make sense when the in content variant is used. Perhaps it would be possible to simply replace this algorithm with try parsing a global date and time, else try parsing a date, else try parsing a time? I haven't check carefully if this is equivalent though. http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-time-element-0 When the time binding applies to a time element, the element is expected to render as if it contained text conveying the date (if known), time (if known), and time-zone offset (if known) represented by the element, in the fashion most convenient for the user. This is very vague. Anything which tries to localize the date/time will fail because guessing the language of web pages is hard. Hard-coding it to English also wouldn't be very nice. What seems to make the most sense is using the best representation of the global date and time string and equivalents for just time and date that have to be defined. Still, I'm not sure this is very useful, as the same rendering (but slightly more flexible) could be accomplished by simply putting the date/time in the content instead of in the attribute. As a bonus, that would degrade gracefully. Unless I'm missing something, I suggest dropping the special rendering requirements for time completely. -- Philip Jägenstedt Opera Software
