Opened 10 years ago
Last modified 3 years ago
#11190 assigned defect
dojo.date.locale.parse handles 'S' token incorrectly
Reported by: | ben hockey | Owned by: | |
---|---|---|---|
Priority: | high | Milestone: | 1.15 |
Component: | Date | Version: | 1.5.0b2 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description
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.
Change History (2)
comment:1 Changed 4 years ago by
Milestone: | tbd → 1.12 |
---|---|
Owner: | Adam Peller deleted |
Status: | new → assigned |
comment:2 Changed 3 years ago by
Milestone: | 1.13 → 1.15 |
---|
Ticket planning... move current 1.13 tickets out to 1.15 to make it easier to move tickets into the 1.13 milestone.