Opened 6 years ago

Last modified 2 years ago

#17895 new defect

date.stamp.fromISOString returns incorrect value around DST

Reported by: steveh Owned by:
Priority: undecided Milestone: 1.14
Component: Date Version: 1.9.3
Keywords: Cc:
Blocked By: Blocking:

Description

I've found that doing the following results in a different object than if i were to parse it with new Date()

Both:
stamp.fromISOString("2014-03-09T02:15:00+00:00")
and
stamp.fromISOString("2014-03-09T01:15:00+00:00")\
Return:
Sat Mar 08 2014 19:15:00 GMT-0600 (Central Standard Time)

OR

stamp.fromISOString("2014-03-09T02:15:00Z")
and
stamp.fromISOString("2014-03-09T01:15:00Z")
Returns:
Sat Mar 08 2014 19:15:00 GMT-0600 (Central Standard Time)

Compared to doing this with the built-in object.

new Date("2014-03-09T02:15:00+00:00")
and
new Date("2014-03-09T02:15:00Z")
Returns:
Sat Mar 08 2014 20:15:00 GMT-0600 (Central Standard Time)

The correct time should be "20:15 CST" not "19:15"

In order to reproduce this you will need a browser in a DST timezone, i used America/Chicago?. The browser i used is also the latest chrome, however i think this might be browser independent.

The reason for this bug is because dojo creates the date object in the naive browser timezone, and then offsets the time. The problem with this is that if the UTC's hour is naively in the browser timezone's DST missing hour, It will subtract 1 hour and move it to 1am, and from there dojo adds the full offset.

This affects any string in the browsers missing hour for all timezones specified in the ISOString it seems.

From what I can see there are 2 options. Convert it from the incoming timezone to the browser timezone before creating the object. Or after creation of the object compare the hours and minutes of each time (from object and match regex array), making sure they are in the same timezone, and add the difference to make them equivalent. Bringing the object to what is represented in the string.

Care will need to be taken to avoid cases where the string explicitly references the missing hour, and that it is pushed back to the 1am hour as this is how the browser handles this case.

Apologies if i've misunderstood the API or created a duplicate ticket, i couldn't find one.

Change History (3)

comment:1 Changed 5 years ago by neville1355

We have also noticed this behaviour but only on Mac OS/Safari. Windows environments + browsers (incl. safari) work correctly.

Is it possible to escalate this at all?

comment:2 Changed 4 years ago by dylan

Milestone: tbd1.12

Would love to get it fixed, but it's going to require someone to either work on a pull request. Alternatively you could ask through SitePen?'s paid support services ( http://sitepen.com/support/ ). Given the lack of attention to this one, I'm not able to provide any guidance on when it's going to get fixed, but I'll mark it for consideration for 1.12.

comment:3 Changed 2 years ago by dylan

Milestone: 1.131.14
Note: See TracTickets for help on using tickets.