2014-05-06 127 views
0

我有類似的日期字符串:在Joda-Time中將日期字符串轉換爲datetime對象?

「2014-04-10T00:00:00.000」

所以我需要將此轉換爲Joda-TimeDateTime對象。

這裏是我的代碼:

String datePattern = "yyyy-MM-dd'T'HH:mm:ss.SSS"; 
DateTimeFormatter dateFormatter = DateTimeFormat.forPattern(datePattern); 

currentCard.setStartDate("2014-04-10T00:00:00.000"); 
currentCard.setEndDate("2015-04-10T00:00:00.000"); 

DateTime startDateTime = dateFormatter.parseDateTime(currentCard.getStartDate()); 
DateTime endDateTime = dateFormatter.parseDateTime(currentCard.getEndDate()); 

if (startDateTime.isBeforeNow() && endDateTime.isAfterNow()) { 
    currentCard.setActive(true); 
} else { 
    currentCard.setActive(false); 
} 

它告訴我string is too short

+0

我已經用Joda-Time 2.1測試了你的代碼,它工作正常。解釋Z.沒問題,您使用的是哪種版本的Joda-Time? –

+0

我正在使用1.6.2 – user2810351

回答

3

相信對於日期模式正確的語法是"yyyy-MM-dd'T'HH:mm:ss.SSS'Z'"。這樣,字面上使用Z

+0

哎呀..!你是正確的謝謝:) – user2810351

+0

如果字符串輸入具有任何類型的偏移量,如「+0200」,您的解決方案將失敗。 –

+0

不,我改變了問題請看看? – user2810351

1

關於使用模式「yyyy-MM-dd'T'HH:mm:ss.SSSZ」進行第一次編輯,並且遇到Z輸入的解析問題,顯然這是版本問題,請參見此處:

Joda-Time-release-notes for change 1.6 to 2.0 =>

「允許在格式模式 'Z' 和 'ZZ' 進行解析 'Z' 爲 '00:00'[2827359]」

所以解決方案是使用最新版本的Joda-Time。請注意,模式符號Z的使用比在模式表達式中使用文字'Z'更強大,因爲任何與ISO-8601兼容的字符串可能不僅在末尾包含「Z」,而且還會像「+0200」 。如果偏移量可能包含冒號(例如「+05:30」),那麼您應該在模式中使用雙ZZ。

評價關於您的編輯刪除圖案符號Z:

在這種情況下,我沒有看到與2.1版的任何異常。 Joda-Time只會將輸入解釋爲系統時區中的本地時間,並添加適當的時區偏移量。無論如何,你必須適應你的模式,以期望的投入,而不是周圍。

3

雖然其他答案是正確的,但答案和你的問題都工作太辛苦。

ISO 8601格式

有問題的字符串的格式, 「2014-04-10T00:00:00.000」,是標準ISO 8601格式。 Joda-Time中的DateTime類具有內置的內置ISO 8601解析器/格式器,默認情況下使用。所以不需要實例化格式化程序。僅僅將字符串傳遞給構造函數DateTime

時區

指定由一個時區來解釋日期時間值。否則,應用JVM當前的默認時區。

實施例:

DateTimeZone timeZoneMontréal = DateTimeZone.forID("America/Montreal"); 

示例代碼

使用Joda-Time 2.5一些示例代碼。

DateTime dateTime = new DateTime("2014-04-10T00:00:00.000", DateTimeZone.UTC); 

如果串表示在Québec而非UTC壁時間†片刻,然後通過指定該字符串應該在解析可以理解,時區。

DateTime dateTime = new DateTime("2014-04-10T00:00:00.000", timeZoneMontréal); 

通過Meno Hochschild指定格式

按照註釋,你可能更願意指定傳入字符串的預期格式。 Joda-Time有許多預先定義的formatters內置的,以及允許你定義你自己的。在這種情況下,我們的字符串在末尾缺少時區偏移量,所以我們指定了格式化程序dateHourMinuteSecondFraction

如果傳入的字符串格式不正確或使用意外的格式會怎麼樣?拋出異常。爲了健壯的代碼,陷入這個異常。

String input = "2014-04-10T00:00:00.000"; 
DateTimeZone timeZoneMontréal = DateTimeZone.forID("America/Montreal"); 
DateTimeFormatter formatter = ISODateTimeFormat.dateHourMinuteSecondFraction().withZone(timeZoneMontréal); 
DateTime dateTime = null; 
try { 
    dateTime = formatter.parseDateTime(input); 
} catch (IllegalArgumentException e) { 
    System.out.println("Unexpected format of incoming date-time string: " + input + ". Exception: " + e); // Handle exception for bad input. 
} 

調整爲UTC進行比較。

DateTime dateTimeUtc = dateTime.withZone(DateTimeZone.UTC); 

轉儲到控制檯。

System.out.println("dateTime: " + dateTime); 
System.out.println("dateTimeUtc: " + dateTimeUtc); 

運行時。

dateTime: 2014-04-10T00:00:00.000-04:00 
dateTimeUtc: 2014-04-10T04:00:00.000Z 

†牆時間=爲通常出現在一些時鐘在一些地方一些牆上的時間。

+1

個人而言,我對這樣的構造函數存在問題,這些構造函數需要字符串輸入的隱式格式。雖然許多用戶可能會發現這種方便,但它也是猜測工作。爲了確保用戶必須查找文檔以查找支持哪種字符串格式。對ISO的提示並不是很有幫助,因爲ISO-8601還定義了其他格式,例如有序日期或星期幾,這些在這裏不受支持。基本的偏移量格式在這樣的構造函數中似乎也是一個問題(沒有冒號)。 –

+0

@MenoHochschild點好了。總的來說,我同意你的評論的主旨。對我而言,我通常使用Joda-Time的特定ISO格式處理日期 - 時間值,因此內置解析器非常方便。但我明白明確的價值,而不是依靠可能的麻煩違約。如果您打算使用明確的格式化程序,我建議您爲格式化程序定義模式,而不是使用[IsoDateTimeFormat](http://www.joda.org/joda- time/apidocs/org/joda/time/format/ISODateTimeFormat.html)工廠。 –

+0

是的,像'IsoDateTimeFormat'這樣的命名常量或命名方法也可以代替模式。 –

相關問題