DateTime.fromISO() doesn't handle timezones with seconds

DateTime.fromISO() can’t parse timezones containing seconds. Note that DateTime.toISO() can create such timezone strings; I believe fromISO() should be able to reverse toISO().

Here’s a brief example:

const { DateTime } = require('luxon')

// Toronto was UTC -5:17:32 from 1850-1894
// https://www.timeanddate.com/time/zone/canada/toronto?syear=1850
const dateString = '1891-05-08 00:00'
console.log('Original date string:   ', dateString)
const luxonDate = DateTime.fromFormat(dateString, 'yyyy-LL-dd HH:mm', {
  zone: 'America/Toronto'
})
console.log('ISO date via luxon:     ', luxonDate.toISO())
const fromISO = DateTime.fromISO(luxonDate)
console.log('fromISO(DateTime):      ', fromISO.invalid)
// truncate the timezone 
const fromISOTruncated = DateTime.fromISO(luxonDate.toISO().substring(0, 29))
console.log('fromISO(truncated):     ', fromISOTruncated.toISO())

Output:

Original date string:    1891-05-08 00:00
ISO date via luxon:      1891-05-08T00:00:00.000-05:17.53333333333336
fromISO(DateTime):       Invalid {
  reason: 'unparsable',
  explanation: `the input "1891-05-08T00:00:00.000-05:17.53333333333336" can't be parsed as ISO 8601`
}
fromISO(truncated):      1891-05-08T00:00:00.000-05:17

For what it’s worth, moment-timezone throws an exception when the timezone has seconds, and miscalculates the ISO date to 1891-05-08T00:17:00-05:00 when they’re truncated.

[GillesDebunne]

Closing as working as intended. Thanks @danilotitato

[GillesDebunne]

The ISO 8601 standard does not mention fractional timezone offsets.

This W3C website says : TZD = time zone designator (Z or +hh:mm or -hh:mm). The ISO8601 wikipedia page has a Time zone designators section that lists the form ±[hh]:[mm], ±[hh][mm], or ±[hh].

Note that #755 now truncs the offset in toISO() to enforce this standard.

As a result, I would close this bug as working as intended, since fromISOdoes not have to support fractional offsets.

Note that cmcleese’s comment above is different and has been moved to a separate issue (#757).