TimeOffset Parser isn't lenient enough

[chrisjenx]

Instant and UtcOffset parsing should allow all ISO offset standards.

• -0330
• -03
• -03:30

Currently it will fail if you miss the + / - sign and or if you miss the :. The spec has this as optional an should be honored when parsing ISO dates.

From the spec:

Time offsets from UTC
The UTC offset is appended to the time in the same way that 'Z' was above, in the form ±[hh]:[mm], ±[hh][mm], or ±[hh].

Negative [UTC offset](https://en.wikipedia.org/wiki/UTC_offset)s describe a time zone west of UTC±00:00, where the civil time is behind (or earlier) than UTC so the zone designator will look like "−03:00","−0300", or "−03".

Positive [UTC offsets](https://en.wikipedia.org/wiki/UTC_offset) describe a [time zone](https://en.wikipedia.org/wiki/Time_zone) at or east of [UTC±00:00](https://en.wikipedia.org/wiki/UTC%C2%B100:00), where the [civil time](https://en.wikipedia.org/wiki/Civil_time) is the same as or ahead (or later) than [UTC](https://en.wikipedia.org/wiki/UTC) so the zone designator will look like "+02:00","+0200", or "+02".

[ilya-g]

The ISO-8601 allows to use two formats for representing date/time values: basic and extended.

UtcOffset supports parsing values in both the basic (±[hh][mm]) and the extended (±[hh]:[mm]) ISO-8601 formats.

Instant on the other hands supports only the extended format by default. We haven't seen evidence that the basic format is used much in practice for representing Instant values (e.g. 20211227T220000+0400).

See details in the answer to #158

Note, that the part of the wikipedia article you're citing is not a normative spec, but rather a short recap of the standard. For a better understanding of it, you can take a look at the subset of the standard that is available as RFC-3339

[dkhalanskyjb]

Fixed in https://github.com/Kotlin/kotlinx-datetime/commit/f18cb890e648e5903b4530f3ed8b7d2115dc6679: now, the documentation states that the extended ISO 8601 format is used.

[chrisjenx]

Thanks chaps!