1 回答
TA貢獻1841條經驗 獲得超3個贊
在您的字符串中,我認為UTC+01是與 UTC 相差 +1 小時。因此,雖然 UTC 可能已被解釋為時區(實際上不是),但這與此處無關,因為字符串中的時間不是 UTC,而是 UTC+01:00。所以我們不應該使用z, time-zone name, 來解析它。這樣做基本上是給你錯誤結果的原因(結合解析成 a ZonedDateTime)。
@VGR 在他/她的評論中是正確的:我們想要'UTC'x. 我僅使用兩個示例,足以證明它們給出了不同的結果。
final DateTimeFormatter formatter = DateTimeFormatter.ofPattern("dd/MM/yy HH:mm:ss 'UTC'x");
String str = "22/04/17 09:24:28 UTC+01";
System.out.println(MessageFormat.format("Parsed String \"{0}\", got result of \"{1}\"",
str, OffsetDateTime.parse(str, formatter)));
str = "22/04/17 09:24:28 UTC+07";
System.out.println(MessageFormat.format("Parsed String \"{0}\", got result of \"{1}\"",
str, OffsetDateTime.parse(str, formatter)));
輸出是:
Parsed String "22/04/17 09:24:28 UTC+01", got result of "2017-04-22T09:24:28+01:00"
Parsed String "22/04/17 09:24:28 UTC+07", got result of "2017-04-22T09:24:28+07:00"
周圍的單引號UTC表示文字文本,因此格式化程序會檢查文本是否存在但對它沒有任何意義。一個x是僅由小時組成的偏移量(除非非零分鐘是偏移量的一部分),例如+01or +12。由于您的字符串包含偏移量并且沒有時區(例如英國時間的歐洲/倫敦),因此OffsetDateTime是表示日期和時間的(最)正確類型。
退一步說,雖然您的格式是人類可讀的,但它是非標準的,不適合機器解析。您可能要考慮是否可以說服字符串的發送者改為給您 ISO 8601 格式,例如2017-04-22T09:24:28+01:00.
添加回答
舉報
