Skip to content
This repository has been archived by the owner on Jul 8, 2022. It is now read-only.

"Not a valid format" when parsing an ISO 8601 string #123

Closed
tspoke opened this issue Jun 26, 2020 · 3 comments · Fixed by #125
Closed

"Not a valid format" when parsing an ISO 8601 string #123

tspoke opened this issue Jun 26, 2020 · 3 comments · Fixed by #125

Comments

@tspoke
Copy link

tspoke commented Jun 26, 2020

Hi,

I'm getting a parsing issue from a raw string to a DateTime, hereafter my code and results.
getBirthdayDate() is implemented in KMP but it is called from an android app.

The KMP source code is very simple :

// birthday == "1989-01-01T10:00:00.000Z"
fun getBirthdayDate(): DateTimeTz? {
        birthDay?.let {
            return DateTime.parse(it)
        }
        return null
}

On android I get this error :

com.soywiz.klock.DateException: Not a valid format: '1989-01-01T10:00:00.000Z' for 'yyyy-MM-dd'T'HH:mm:ssXXX'
        at com.soywiz.klock.DateFormatKt.parse(DateFormat.kt:32)
        at com.soywiz.klock.DateFormat$Companion.parse(DateFormat.kt:19)
        at com.soywiz.klock.DateTime$Companion.fromString(DateTime.kt:182)

I tried to remove the timezone Zulu character but I still have the same error :

com.soywiz.klock.DateException: Not a valid format: '1989-01-01T10:00:00.000' for 'yyyy-MM-dd'T'HH:mm:ssXXX'
        at com.soywiz.klock.DateFormatKt.parse(DateFormat.kt:32)
        at com.soywiz.klock.DateFormat$Companion.parse(DateFormat.kt:19)
        at com.soywiz.klock.DateTime$Companion.fromString(DateTime.kt:182)

If I remove the milliseconds, it works has expected. Is it by design ?

Version : 1.11.12

@RezMike
Copy link

RezMike commented Jun 26, 2020

The default formats don't take milliseconds into account. Try this line of code:

DateFormat("yyyy-MM-dd'T'HH:mm:ss.SSSz").parse(it)

@tspoke
Copy link
Author

tspoke commented Jul 1, 2020

I was expecting from a date-time library to be able to parse correctly at least an ISO 8601 format (with optional ms). Is it by design ?
IMO this format should be handled correctly by default.

@RezMike
Copy link

RezMike commented Jul 1, 2020

Good point. I've fixed it here #125

@RezMike RezMike linked a pull request Jul 1, 2020 that will close this issue
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants