Sugar: Date.create parses "2012-12-20T20:00:00.000Z" incorrectly
For some ISO dates, Date.create incorrectly parses the month for 01, 02, 03, and 12. My expectation is that Date.create(s).iso() == s for all valid ISO dates.
I have observed this behavior on Linux Chrome 18, Linux Firefox 12, and Windows Chrome 19. I’m not sure if there are any local clock dependencies in sugar.js, but for reference my local timezone is PDT and I’ve observed the failed tests both in the morning and the evening local time.
I believe that this bug does have some dependency on the real world calendar because I have other application specific tests that depend on correct behavior of Date.create that were passing earlier this week and started failing yesterday. The tests began failing without a source code change (I was running sugar.js 1.2.3 at the time). I recently upgraded to sugar.js 1.2.5, and these tests fail in that environment.
same(Date.create('2010-01-20T20:00:00.000Z').iso(), '2010-01-20T20:00:00.000Z') // FAILS!!
same(Date.create('2010-02-20T20:00:00.000Z').iso(), '2010-02-20T20:00:00.000Z') // FAILS!!
same(Date.create('2010-03-20T20:00:00.000Z').iso(), '2010-03-20T20:00:00.000Z') // FAILS!!
same(Date.create('2010-04-20T20:00:00.000Z').iso(), '2010-04-20T20:00:00.000Z')
same(Date.create('2010-05-20T20:00:00.000Z').iso(), '2010-05-20T20:00:00.000Z')
same(Date.create('2010-05-20T20:00:00.000Z').iso(), '2010-05-20T20:00:00.000Z')
same(Date.create('2010-06-20T20:00:00.000Z').iso(), '2010-06-20T20:00:00.000Z')
same(Date.create('2010-07-20T20:00:00.000Z').iso(), '2010-07-20T20:00:00.000Z')
same(Date.create('2010-08-20T20:00:00.000Z').iso(), '2010-08-20T20:00:00.000Z')
same(Date.create('2010-09-20T20:00:00.000Z').iso(), '2010-09-20T20:00:00.000Z')
same(Date.create('2010-10-20T20:00:00.000Z').iso(), '2010-10-20T20:00:00.000Z')
same(Date.create('2010-11-20T20:00:00.000Z').iso(), '2010-11-20T20:00:00.000Z')
same(Date.create('2010-12-20T20:00:00.000Z').iso(), '2010-12-20T20:00:00.000Z') // FAILS!!
Thanks for the quick patch for the bug I reported yesterday - hope you are able to track this one down quickly as well because it has the potential to be a serious issue for my customers in short order.
About this issue
- Original URL
- State: closed
- Created 12 years ago
- Reactions: 1
- Comments: 16 (10 by maintainers)
Commits related to this issue
- fixing #146 concerning DST traversal — committed to andrewplummer/Sugar by andrewplummer 12 years ago
- fixing #146 concerning DST traversal — committed to andrewplummer/Sugar by andrewplummer 12 years ago
👍 Using
new Date('2010-01-20T20:00:00.000Z')
is an acceptable workaround for now, but that only works with the ISO8601 format.