3 回答

TA貢獻(xiàn)1757條經(jīng)驗(yàn) 獲得超8個(gè)贊
格式的時(shí)區(qū)部分需要一個(gè)前導(dǎo) + 或 - 字符。因此,您提供的字符串失敗了。如果您嘗試使用“20190911T14:37:08.777 + 0400”,它會(huì)起作用。
我沒(méi)有看到任何可與沒(méi)有符號(hào)的 4 位時(shí)區(qū)偏移一起使用的選項(xiàng)。?

TA貢獻(xiàn)1842條經(jīng)驗(yàn) 獲得超22個(gè)贊
使用正確的格式代碼。
輸入意味著微秒范圍內(nèi)的小數(shù)秒?
如果最后的數(shù)字代表秒的一小部分,則此代碼有效。用七位數(shù)字來(lái)表示秒的小數(shù)部分是不尋常的;3(3、6 或 9)的增量更為常見。但我們可以讓它發(fā)揮作用。
String input = "20190911T14:37:08.7770400" ;
DateTimeFormatter f = DateTimeFormatter.ofPattern( "uuuuMMdd'T'HH:mm:ss.SSSSSSS" ) ;?
LocalDateTime ldt = LocalDateTime.parse( input , f ) ;
ldt.toString(): 2019-09-11T14:37:08.777040
輸入意味著偏移?輸入錯(cuò)誤。
如果最后的數(shù)字是以毫秒為單位的小數(shù)秒和與 UTC 的偏移量(小時(shí)數(shù)和分鐘數(shù))的四位數(shù)字的組合,那么您的輸入就有錯(cuò)誤。偏移量要么早于 UTC,要么晚于 UTC。因此偏移量必須包含加號(hào)+
或減號(hào)-
。您的輸入兩者都沒(méi)有,因此無(wú)法解析此類字符串的相對(duì) UTC 偏移量。
ISO 8601
輸入字符串的格式很糟糕,顯然是對(duì)標(biāo)準(zhǔn)ISO 8601格式的笨拙修改。例如:2013-04-03T17:04:39.9437823+04:00
.?我強(qiáng)烈建議您對(duì)這些數(shù)據(jù)的發(fā)布者進(jìn)行有關(guān) ISO 8601 標(biāo)準(zhǔn)的教育。不要發(fā)明新格式,堅(jiān)持標(biāo)準(zhǔn)。
java.time類在解析/生成字符串時(shí)默認(rèn)使用ISO 8601格式。因此,根本不需要指定格式模式!
另一件事:如果您嘗試跟蹤時(shí)間軸上的時(shí)刻、實(shí)際點(diǎn),那么您必須在輸入中包含偏移量或時(shí)區(qū)。如果沒(méi)有這種背景,我們不知道輸入是否意味著日本東京的下午 2 點(diǎn)或美國(guó)俄亥俄州托萊多的下午 2 點(diǎn)——兩個(gè)截然不同的時(shí)刻,相隔幾個(gè)小時(shí)。

TA貢獻(xiàn)1871條經(jīng)驗(yàn) 獲得超8個(gè)贊
String dateFormatter ="20190911T14:37:08.777+0400";
SimpleDateFormat sdf = new SimpleDateFormat("yyyyMMdd'T'HH:mm:ss.SSSZZZZ");
try {
System.out.println(sdf.parse(dateFormatter));
} catch (Exception ex) {
System.out.println(ex);
}
添加 + 應(yīng)該可以,并檢查它是“yyyyMMdd”而不是“YYYYMMDD”。
添加回答
舉報(bào)