给出yyyy-mm-ddthh：mm：ss formate异常的ThreeTenABP DateTime解析器

Question

我需要将dateTime字符串转换为millis，为此我使用了ThreeTenABP，但是offsetDateTime.parse无法解析用于ex的dateTime字符串。“2020-08-14T20:05:00”并给出以下例外情况。

Caused by: org.threeten.bp.format.DateTimeParseException:  
Text '2020-09-22T20:35:00' could not be parsed:  
Unable to obtain OffsetDateTime from TemporalAccessor:  
DateTimeBuilder[, ISO, null, 2020-09-22, 20:35], type org.threeten.bp.format.DateTimeBuilder

我已经搜索过类似的问题，但找不到确切的解决方案。

下面是我在Kotlin中使用的代码。

val formatter: DateTimeFormatter = DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss",
                                                                Locale.ROOT)
val givenDateString = event?.eventDateTime
val timeInMillis = OffsetDateTime.parse(givenDateString, formatter)
                                    .toInstant()
                                    .toEpochMilli()

Answer 1

问题是字符串中缺少偏移量，您试图将其解析为offsetdatetime。如果没有ZoneOffset，则无法创建OFFSetDateTime，但是不能从这个字符串派生ZoneOffset（可以猜测它是UTC，但是在这种情况下猜测是不合适的）。

您可以将字符串解析为LocalDateTime（一天中没有区域或偏移量的日期和时间的表示形式），然后添加/附加所需的偏移量。您甚至不需要自定义DateTimeFormatter，因为您的字符串是ISO格式的，可以使用默认的内置格式化程序解析：

fun main() {
    // example String
    val givenDateString = "2020-09-22T20:35:00"
    // determine the zone id of the device (you can alternatively set a fix one here)
    val localZoneId: ZoneId = ZoneId.systemDefault()
    // parse the String to a LocalDateTime
    val localDateTime = LocalDateTime.parse(givenDateString)
    // then create a ZonedDateTime by adding the zone id and convert it to an OffsetDateTime
    val odt: OffsetDateTime = localDateTime.atZone(zoneId).toOffsetDateTime()
    // get the time in epoch milliseconds
    val timeInMillis = odt.toInstant().toEpochMilli()
    // and print it
    println("$odt ==> $timeInMillis")
}

这个示例代码产生以下输出（注意datetime表示形式中后面的z，这是+00:00小时的偏移量，UTC时区，我在Kotlin Playground写了这段代码，它似乎有UTC时区；-)):

2020-09-22T20:35Z ==> 1600806900000

请注意，我使用java.time而不是ThreeTen ABP进行了尝试，ThreeTen ABP对于许多（较低的）Android版本来说已经过时了，因为有Android API desugring。但是，这不会有什么不同，因为当我第一次尝试时，您的示例代码抛出了完全相同的异常，这意味着ThreeTen不应该为此负责。