`fromString` of a Local Time incorrectly treats it as having an offset of 0

[r-k-b]

This silently corrupts incoming data that isn't already known to have an offset of zero.

For example, when parsing user input which is implicitly in their local time:

> ISO8601.fromString "2016-04-19T15:08:41.083"
Ok { day = 19, hour = 15, millisecond = 83, minute = 8, month = 4, offset = (0,0), second = 41, year = 2016 }

The output is incorrectly given an arbitrary offset.

Some options:

• Change the internal representation to allow unspecified offsets.
• Require a Timezone to parse ambiguous (local) times.
• Reject parsing of ambiguous times.

This fabrication of made-up timezones also affects date-only strings. The following example converts some local Date to the Date specific to zones with a zero offset:

> ISO8601.fromString("2020-01-01")
Ok { day = 1, hour = 0, millisecond = 0, minute = 0, month = 1, offset = (0,0), second = 0, year = 2020 }

---

For reference, Moment.js appears have different behaviour, treating local times as runtime-specific. For example:

> moment("2016-04-19T15:08:41.083").toISOString()
"2016-04-19T05:08:41.083Z"
``

[jweir]

Moment has access to the local timezone via the Browser, which Elm does not have.

The third option is really the only feasible path forward, although it is a valid ISO8601 format, just ambiguous as you point out.

Ultimately though this library is meant to be a pragmatic tool, not a perfect tool. It serves our needs to very quickly parse time strings for use in grouping by hour and date (which is why we don't use Posix internally).

I will think about this for a while.