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. `._.-(,_..'--(,_..'`-.;.'
