我試圖修改現有的 java 代碼以毫秒而不是秒為單位輸出數據。以秒為單位返回格林威治標準時間當前時間的現有代碼：currentTime = LocalDateTime.now().toEpochSecond(ZoneOffset.UTC);輸出currentTime = 1566311076它說使用紀元轉換器GMT: Tuesday, August 20, 2019 2:24:36 PMYour time zone: Tuesday, August 20, 2019 7:24:36 AM GMT-07:00 DST我嘗試修改 java 代碼以返回以毫秒為單位的 GMT 中的當前時間能夠以毫秒為單位獲取當前系統時間，但是如何將結果偏移到 GMT 時間。currentTime = ZonedDateTime.now().toInstant().toEpochMilli();輸出currentTime = 1566336256566假設這個時間戳是毫秒GMT: Tuesday, August 20, 2019 9:24:16.566 PMYour time zone: Tuesday, August 20, 2019 2:24:16.566 PM GMT-07:00 DST你知道嗎，會非常感激的。謝謝！
2 回答
慕少森
TA貢獻2019條經驗 獲得超9個贊
轉換為Instant第一個：
currentTime = LocalDateTime.now().toInstant(ZoneOffset.UTC).toEpochMilli()
演示
System.out.println(LocalDateTime.now().toEpochSecond(ZoneOffset.UTC));
System.out.println(LocalDateTime.now().toInstant(ZoneOffset.UTC).toEpochMilli());
輸出
1566323773
1566323773363
繁花如伊
TA貢獻2012條經驗 獲得超12個贊
當存在簡單的方法時，為什么要以更復雜的方式進行呢？
long currentTime; currentTime = System.currentTimeMillis(); System.out.println(currentTime);
剛才的示例輸出：
1566369127348
我強烈支持使用現代 java.time 類，包括ZonedDateTime（可能不多LocalDateTime）。然而，在這種情況下，Java 誕生時的一個簡單方法給了我們想要的東西。我認為使用它沒有問題。如果您確實想使用 java.time，請使用Instant：
currentTime = Instant.now().toEpochMilli(); System.out.println(currentTime);
1566369127348
你的代碼出了什么問題？
奇怪的是你的舊代碼不正確。您的新嘗試給出了自紀元以來的正確毫秒數。您的舊代碼是：
currentTime = LocalDateTime.now().toEpochSecond(ZoneOffset.UTC);
這將采用您所在時區的當前掛鐘時間，或者更準確地說，采用 JVM 的默認時區。然后它錯誤地假設時間是 UTC，并根據這個假設將它轉換為自紀元以來的秒數（當然，如果 JVM 的時區是 UTC，你會碰巧得到正確的結果）。
我建議您始終將時區（如果不是時鐘）傳遞給一種now方法，以使您對所用時區的期望明確。no-argnow使用 JVM 的默認時區，這是不可靠的，因為設置可能會意外更改，并可能導致混淆。如果在上面的代碼行中寫明了時區，我們一眼就能看出它是否符合后面假設的UTC。例外是 Instant.now()：它不需要時區，因為它在所有時區都給出相同的結果。
我在歐洲/哥本哈根時區的計算機上舊代碼的輸出是：
1566376327
您可以看到它與我們之前獲得的毫秒值不一致（在本例中它提前了兩個小時；在您的情況下它落后了 7 小時）。
您的問題似乎已在格林威治標準時間晚上 10 點（22:00）左右（偏移量 -07:00 下午 3 點）發布，因此您的結果都不符合那個時間。從運行您的代碼到發布您的問題已經過去了幾個小時；或者您的計算機時鐘設置不正確。
添加回答
舉報
0/150
提交
取消