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
new Date('10 20 2021 08:00').toISOString()
// 2021-10-20T12:00:00.000Z
Date.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.
new Date('10 20 2021 08:00')
// Invalid Date
Date.create('10 20 2021 08:00', { fromUTC: true })
// Invalid Date
Date.create('10.20.2021 08:00', { fromUTC: true }).toISOString()
// 2021-10-20T08:00:00.000Z
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.