![](/img/trans.png)
[英]ISO 8601 DateTimeFormatter truncates the ms of this format:'YYYY-MM-DDTHH:mm:ss.sssZ'
[英]Understanding specific UTC time format YYYY-MM-DDTHH:MM:SS.SSSZ
我有兩個相關的問題。
假設在 BST 中運行的程序以 UTC YYYY-MM-DDTHH:MM:SS.SSSZ 格式生成當前時間的日期時間值
還假設倫敦的當前時間是 2016-06-01 12:33:54
如果程序給出的當前時間是 2016-06-01T11:33:54.000Z ,是不是程序出錯了?
BST 的夏季偏移如何以 YYYY-MM-DDTHH:MM:SS.SSSZ 的相應時間格式記錄
我假設 YYYY-MM-DDTHH:MM:SS+0001 我正確嗎?
首先請閱讀iso8601信息。 處理不同時區(例如服務器時區和客戶端時區)的時間變得越來越普遍,並且該標准非常有用。
特別是請在此處閱讀 UTC 或“祖魯”時間。
程序是正確的,因為倫敦時間比夏季的“UTC”時間提前一小時
尾隨的“Z”是 UTC(祖魯語)的縮寫。 你也可以寫“+00:00”而不是“Z”。 SS.SSS 指的是秒和毫秒 - 與時區無關。 在 devnull 的評論中,他向您展示了如何為夏季應用偏移量。
編輯:
評論中有一些關於iso8601時區是否包含時區以及時區是否會被打印出來的討論。
這完全取決於日期/時間實現。 如果我們使用SimpleDateFormat
則支持時區並將被打印。
這是一個代碼示例來說明
SimpleDateFormat formatter = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSSXXX");
formatter.setTimeZone(TimeZone.getTimeZone("UTC"));
System.out.println(formatter.format(new Date()));
formatter.setTimeZone(TimeZone.getTimeZone("Europe/London"));
System.out.println(formatter.format(new Date()));
輸出
2016-06-02T12:53:14.924Z
2016-06-02T13:53:14.925+01:00
自然,如果您使用不同的日期/時間庫,例如joda-time
,那么實現細節將有所不同。
編輯:正如@DerrylThomas 指出的, SimpleDateFormat
明智地使用小寫y多年 - 除非它打算使用周年 - 在另一個類似問題的答案中詳細解釋了https://stackoverflow.com/a/56911450 .
如果程序給出的當前時間是 2016-06-01T11:33:54.000Z ,是不是程序出錯了?
格式正確且符合ISO 8601,但不代表歐洲/倫敦時間。 在2016年的倫敦,夏令時從3 月 27 日星期日凌晨 1 點開始,到 10 月 30 日星期日凌晨 2 點結束,因此在此期間歐洲/倫敦的日期時間表示應具有時區偏移+01:00
小時。 末尾的Z
指定Zulu
時間,即 UTC 時間,因此時區偏移為+00:00
小時。 歐洲/倫敦的同一時刻可以表示為2016-06-01T12:33:54+01:00
。
java.util
日期時間 API 及其格式化 API SimpleDateFormat
已過時且容易出錯。 建議完全停止使用它們並切換到java.time
, 現代日期時間 API * 。
甚至Joda-Time也不應該再使用了。 請注意Joda-Time 主頁上的以下說明
Joda-Time 是 Java SE 8 之前的 Java 事實標准日期和時間庫。現在要求用戶遷移到 java.time (JSR-310)。
java.time
API 基於ISO 8601
和日期時間字符串, 2016-06-01T11:33:54.000Z
可以解析為java.time.ZonedDateTime
和java.time.OffsetDateTime
而無需日期時間解析/格式化類型。
演示:
import java.time.ZoneId;
import java.time.ZonedDateTime;
public class Main {
public static void main(String[] args) {
ZonedDateTime zdt = ZonedDateTime.parse("2016-06-01T11:33:54.000Z");
System.out.println(zdt);
ZoneId zoneId = ZoneId.of("Europe/London");
ZonedDateTime zdtInLondon = zdt.withZoneSameInstant(zoneId);
System.out.println(zdtInLondon);
}
}
輸出:
2016-06-01T11:33:54Z
2016-06-01T12:33:54+01:00[Europe/London]
如前所述,日期時間字符串2016-06-01T11:33:54.000Z
也可以解析為java.time.OffsetDateTime
而無需日期時間解析/格式化類型。 然而, OffsetDateTime
被設計為處理固定的時區偏移,而ZonedDateTime
被設計為處理時區,因此它會自動處理 DST。 您可以將轉換ZonedDateTime
到OffsetDateTime
使用ZonedDateTime#toOffsetDateTime
如果需要的話。
import java.time.ZonedDateTime;
import java.time.format.DateTimeFormatter;
import java.util.Locale;
public class Main {
public static void main(String[] args) {
DateTimeFormatter dtf = DateTimeFormatter.ofPattern("uuuu-MM-dd'T'HH:mm:ss.SSS z", Locale.ENGLISH);
String strDateTime = "2016-03-01T11:33:54.000 Europe/London";
ZonedDateTime zdt = ZonedDateTime.parse(strDateTime, dtf);
System.out.println(zdt);
strDateTime = "2016-06-01T11:33:54.000 Europe/London";
zdt = ZonedDateTime.parse(strDateTime, dtf);
System.out.println(zdt);
}
}
輸出:
2016-03-01T11:33:54Z[Europe/London]
2016-06-01T11:33:54+01:00[Europe/London]
請注意時區偏移如何自動從Z
更改為01:00
以反映 DST 更改。 另一方面,
import java.time.OffsetDateTime;
public class Main {
public static void main(String[] args) {
String strDateTime = "2016-03-01T11:33:54.000+01:00";
OffsetDateTime odt = OffsetDateTime.parse(strDateTime);
System.out.println(odt);
strDateTime = "2016-06-01T11:33:54.000+01:00";
odt = OffsetDateTime.parse(strDateTime);
System.out.println(odt);
}
}
輸出:
2016-03-01T11:33:54+01:00
2016-06-01T11:33:54+01:00
在這種情況下,您不談論時區(例如歐洲/倫敦); 相反,您談論的是+01:00
小時的固定時區偏移。
從Trail: Date Time 中了解有關現代日期時間 API 的更多信息。
* 出於任何原因,如果您必須堅持使用 Java 6 或 Java 7,您可以使用ThreeTen-Backport,它將大部分java.time功能向后移植到 Java 6 和 7。如果您正在為 Android 項目和您的 Android API 工作級別仍然不符合 Java-8,請檢查 通過 desugaring和How to use ThreeTenABP in Android Project 可用的 Java 8+ APIs 。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.