2 回答

TA貢獻(xiàn)2019條經(jīng)驗(yàn) 獲得超9個(gè)贊
轉(zhuǎn)換為Instant第一個(gè):
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貢獻(xiàn)2012條經(jīng)驗(yàn) 獲得超12個(gè)贊
當(dāng)存在簡單的方法時(shí),為什么要以更復(fù)雜的方式進(jìn)行呢?
long currentTime; currentTime = System.currentTimeMillis(); System.out.println(currentTime);
剛才的示例輸出:
1566369127348
我強(qiáng)烈支持使用現(xiàn)代 java.time 類,包括ZonedDateTime
(可能不多LocalDateTime
)。然而,在這種情況下,Java 誕生時(shí)的一個(gè)簡單方法給了我們想要的東西。我認(rèn)為使用它沒有問題。如果您確實(shí)想使用 java.time,請使用Instant
:
currentTime = Instant.now().toEpochMilli(); System.out.println(currentTime);
1566369127348
你的代碼出了什么問題?
奇怪的是你的舊代碼不正確。您的新嘗試給出了自紀(jì)元以來的正確毫秒數(shù)。您的舊代碼是:
currentTime = LocalDateTime.now().toEpochSecond(ZoneOffset.UTC);
這將采用您所在時(shí)區(qū)的當(dāng)前掛鐘時(shí)間,或者更準(zhǔn)確地說,采用 JVM 的默認(rèn)時(shí)區(qū)。然后它錯(cuò)誤地假設(shè)時(shí)間是 UTC,并根據(jù)這個(gè)假設(shè)將它轉(zhuǎn)換為自紀(jì)元以來的秒數(shù)(當(dāng)然,如果 JVM 的時(shí)區(qū)是 UTC,你會(huì)碰巧得到正確的結(jié)果)。
我建議您始終將時(shí)區(qū)(如果不是時(shí)鐘)傳遞給一種now
方法,以使您對所用時(shí)區(qū)的期望明確。no-argnow
使用 JVM 的默認(rèn)時(shí)區(qū),這是不可靠的,因?yàn)樵O(shè)置可能會(huì)意外更改,并可能導(dǎo)致混淆。如果在上面的代碼行中寫明了時(shí)區(qū),我們一眼就能看出它是否符合后面假設(shè)的UTC。例外是 Instant.now()
:它不需要時(shí)區(qū),因?yàn)樗谒袝r(shí)區(qū)都給出相同的結(jié)果。
我在歐洲/哥本哈根時(shí)區(qū)的計(jì)算機(jī)上舊代碼的輸出是:
1566376327
您可以看到它與我們之前獲得的毫秒值不一致(在本例中它提前了兩個(gè)小時(shí);在您的情況下它落后了 7 小時(shí))。
您的問題似乎已在格林威治標(biāo)準(zhǔn)時(shí)間晚上 10 點(diǎn)(22:00)左右(偏移量 -07:00 下午 3 點(diǎn))發(fā)布,因此您的結(jié)果都不符合那個(gè)時(shí)間。從運(yùn)行您的代碼到發(fā)布您的問題已經(jīng)過去了幾個(gè)小時(shí);或者您的計(jì)算機(jī)時(shí)鐘設(shè)置不正確。
添加回答
舉報(bào)