Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#5751 closed defect (fixed)

dojo.date.stamp.toISOString should create 4-digit year

Reported by: guest Owned by: Adam Peller
Priority: high Milestone: 1.1
Component: Date Version: 1.0
Keywords: date toISOString fromISOString year Cc: epoulin@…, thomas.jenkins@…, wolfram
Blocked By: Blocking:

Description

dojo.date.stamp.toISOString does not create the correct 4-digit year (required by dojo.date.stamp.fromISOString). E.g. converting the date 123-1-1 (first of jan of the year 123) will create 123-01-01 but should create 0123-01-01! "123-01-01" can not be parsed using fromISOString (the regex requires 4-digit year).

Attachments (1)

5751.patch (2.9 KB) - added by Adam Peller 12 years ago.
support years 100-9999

Download all attachments as: .zip

Change History (9)

comment:1 Changed 12 years ago by Adam Peller

Priority: highnormal

true, it also doesn't support years < 0001 or > 9999, which I think the standard does support. Should we bother, or just document the limitation? Is this really high priority?

comment:2 Changed 12 years ago by guest

Ok... I guess documenting the limitation is one way of solving the problem - but it doesn't help the framework (and why call it "ISO"-anything if it isn't?). The fact that you can't "fromISOString" something you created using "toISOString" makes it - well - unusable. No matter what ISO says and if dojo is truly compatible with the ISO standard, "toISOString" SHOULD be compatible with "fromISOString".

comment:3 Changed 12 years ago by Douglas Hays

instead of

 date = [dateObject[getter+"FullYear"](),blahblah

toISOString could do

var year = dateObject[getter+"FullYear"]();
date = ["0000".substr(year.toString().length)+year, blahblah

comment:4 Changed 12 years ago by Adam Peller

It's all about compromise. This code was optimized and kept relatively lean, and there are year limitations on the other date routines too, it seems (e.g. #4850). It's hard to justify adding more code and complexity to extend the range... and even if we did this, years before '1' wouldn't roundtrip or comply with the strict standard, so you could continue to make the same complaint. I'll do some timings. Doug's solution is very concise.

Changed 12 years ago by Adam Peller

Attachment: 5751.patch added

support years 100-9999

comment:5 Changed 12 years ago by Adam Peller

Cc: epoulin@… thomas.jenkins@… added

adding Doug's patch to pad the year to 4 digits has a 1% performance impact. Calling setFullYear on Date to get the last 1-100 years has a 10% performance impact.

comment:6 Changed 12 years ago by Adam Peller

Milestone: 1.1

need to change docs to reflect the status for 1.1

comment:7 Changed 12 years ago by Adam Peller

Resolution: fixed
Status: newclosed

(In [12561]) Years < 100 are not supported. Pad years < 1000 when formatting. Fixes #5751

comment:8 Changed 12 years ago by Adam Peller

Cc: wolfram added

accidentally checked in test with [12491]

Note: See TracTickets for help on using tickets.