dojo.date.locale.parse handles 'S' token incorrectly

[ben hockey]

according to ​http://www.unicode.org/reports/tr35/tr35-4.html#Date_Format_Patterns 'S' is supposed to be "Fractional Second - rounds to the count of letters" but it is currently always being handled as milliseconds only.

if you look carefully at something like this

dojo.date.locale.parse("2010-05-21 09:39:03.455229", {datePattern: 'yyyy-MM-dd', timePattern: 'HH:mm:ss.SSSSSS'})

you will find that it's treating '455229' as milliseconds which then becomes equivalent to 455.229 seconds and so in firefox (didn't try other browsers) the resulting time becomes 9:46:38.229.

there is a note in dojo.date.locale.parse (line 446)

	// Check for overflow.  The Date() constructor normalizes things like April 32nd...
	//TODO: why isn't this done for times as well?

but i couldn't find an open bug so since i've stumbled across this problem i thought i'd open a ticket.

the same problem also causes

dojo.date.locale.parse("2010-05-21 09:39:03.4", {datePattern: 'yyyy-MM-dd', timePattern: 'HH:mm:ss.S'})

to treat the '4' as milliseconds rather than as tenths and so the time ends up with 03.004 seconds when it should be 03.4 seconds.

the way the code is currently, the 'S' token is only handled properly when it is used as 'SSS'.

currently i work around it by using a timePattern like 'HH:mm:ss.X' which causes all the fractions of a second to be ignored since 'X' (or any other token not having meaning) will be ignored. this works out ok because i don't really care about fractions of a second (or seconds) except for when they overflow and throw off the minutes.

[dylan]

Ticket planning... move current 1.13 tickets out to 1.15 to make it easier to move tickets into the 1.13 milestone.