You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This fallback logic seems to be adding the tzOffset when it should be subtracting. At least, that would give a more consistent result. There may be some purpose for adding the tzOffset, but I'm not sure what that is.
The following examples are in the EDT (-04:00) time zone. The expected behavior is for the second and third results to match.
Chrome
newDate('10 20 2021 08:00').toISOString()// 2021-10-20T12:00:00.000ZDate.create('10 20 2021 08:00',{fromUTC: true}).toISOString()// 2021-10-20T16:00:00.000Z// Adds four hours instead of subtracting four hours.Date.create('10.20.2021 08:00',{fromUTC: true}).toISOString()// 2021-10-20T08:00:00.000Z// Sugar's native fromUTC parsing results in a toISOString that matches the input.
Safari
This is just to prove we're falling back to browser-specific parsing.
This fallback logic seems to be adding the tzOffset when it should be subtracting. At least, that would give a more consistent result. There may be some purpose for adding the tzOffset, but I'm not sure what that is.
The following examples are in the EDT (-04:00) time zone. The expected behavior is for the second and third results to match.
Chrome
Safari
This is just to prove we're falling back to browser-specific parsing.
The text was updated successfully, but these errors were encountered: