UtcOffset.parse inconsistency

[silverhammermba]

With version 0.4.0, this passes

val x = UtcOffset.parse("+4")
val y = UtcOffset.parse("+04")
assertEquals(x, y)

This fails

val a = UtcOffset.parse("+4:00")
val b = UtcOffset.parse("+04:00")
assertEquals(a, b)

My understanding of the standard is that +4 should be invalid, but I care more that the parsing is consistent.

[ilya-g]

Indeed, the representation ±h is supported, and ±h:mm is not. This behavior is similar to the behavior java.time.ZoneOffset.of, which is used to parse UtcOffset values.

[silverhammermba]

I was surprised because this behavior was replicated even in the native implementation where ZoneOffset.of is not available. So the spec for method is ISO8601 plus "±h"? The docs do not mention this at all:

kotlinx-datetime/core/common/src/UtcOffset.kt

Lines 39 to 47 in 5a920ea

	* Parses a string that represents an offset in an ISO-8601 time shift extended format, also supporting
	* specifying the number of seconds or not specifying the number of minutes.
	*
	* Examples of valid strings:
	* - `Z` or `+00:00`, an offset of zero;
	* - `+05`, five hours;
	* - `-02`, minus two hours;
	* - `+03:30`, three hours and thirty minutes;
	* - `+01:23:45`, an hour, 23 minutes, and 45 seconds.

[ilya-g]

The standard is not very clear about the number of digits in the hours component of time shift.

I agree that we can at least document the list of supported formats more precisely, and consider if supporting ±h:mm in UtcOffset.parse by default would be of use.

[dkhalanskyjb]

@silverhammermba, since you're the one who encountered this inconsistency, could you explain how it affected you? There's a pull request for custom patterns in parsing and formatting (https://github.com/Kotlin/kotlinx-datetime/pull/251)—would that solve your problem?

[silverhammermba]

The surprise in the default behavior is the bug, in my opinion. It's easy enough to write a custom parser for this case if needed.

In my case I'm working on a client and server. The server was sending the non-standard "+h" format, which was working. When it started sending the (also non-standard) "+h:mm" format the client failed. I ended up just correcting the server to avoid the non-standard cases entirely.

If the docs were clearly updated to indicate the one supported non-standard format, that would also be sufficient to call the bug closed.

[dkhalanskyjb]

Fixed in f83b355