kotlinx-datetime icon indicating copy to clipboard operation
kotlinx-datetime copied to clipboard

UtcOffset.parse inconsistency

Open silverhammermba opened this issue 3 years ago • 5 comments

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.

silverhammermba avatar Nov 01 '22 16:11 silverhammermba

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.

ilya-g avatar Nov 01 '22 17:11 ilya-g

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: https://github.com/Kotlin/kotlinx-datetime/blob/5a920eaee7d640f4f5f7c956eb6706f7b333de81/core/common/src/UtcOffset.kt#L39-L47

silverhammermba avatar Nov 01 '22 17:11 silverhammermba

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.

ilya-g avatar Nov 01 '22 17:11 ilya-g

@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?

dkhalanskyjb avatar Dec 01 '23 15:12 dkhalanskyjb

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.

silverhammermba avatar Dec 01 '23 17:12 silverhammermba

Fixed in https://github.com/Kotlin/kotlinx-datetime/commit/f83b35556d074b11a5a9686bdf1ed8f3d213d997

dkhalanskyjb avatar Mar 11 '24 13:03 dkhalanskyjb