第七色在线视频,2021少妇久久久久久久久久,亚洲欧洲精品成人久久av18,亚洲国产精品特色大片观看完整版,孙宇晨将参加特朗普的晚宴

為了賬號(hào)安全,請及時(shí)綁定郵箱和手機(jī)立即綁定
已解決430363個(gè)問題,去搜搜看,總會(huì)有你想問的

以毫秒為單位將當(dāng)前系統(tǒng)時(shí)間偏移到時(shí)區(qū) GMT

以毫秒為單位將當(dāng)前系統(tǒng)時(shí)間偏移到時(shí)區(qū) GMT

至尊寶的傳說 2023-06-14 16:43:52
我試圖修改現(xiàn)有的 java 代碼以毫秒而不是秒為單位輸出數(shù)據(jù)。以秒為單位返回格林威治標(biāo)準(zhǔn)時(shí)間當(dāng)前時(shí)間的現(xiàn)有代碼:currentTime = LocalDateTime.now().toEpochSecond(ZoneOffset.UTC);輸出currentTime = 1566311076它說使用紀(jì)元轉(zhuǎn)換器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 中的當(dāng)前時(shí)間能夠以毫秒為單位獲取當(dāng)前系統(tǒng)時(shí)間,但是如何將結(jié)果偏移到 GMT 時(shí)間。currentTime = ZonedDateTime.now().toInstant().toEpochMilli();輸出currentTime = 1566336256566假設(shè)這個(gè)時(shí)間戳是毫秒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你知道嗎,會(huì)非常感激的。謝謝!
查看完整描述

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


查看完整回答
反對 回復(fù) 2023-06-14
?
繁花如伊

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è)置不正確。


查看完整回答
反對 回復(fù) 2023-06-14
  • 2 回答
  • 0 關(guān)注
  • 200 瀏覽

添加回答

舉報(bào)

0/150
提交
取消
微信客服

購課補(bǔ)貼
聯(lián)系客服咨詢優(yōu)惠詳情

幫助反饋 APP下載

慕課網(wǎng)APP
您的移動(dòng)學(xué)習(xí)伙伴

公眾號(hào)

掃描二維碼
關(guān)注慕課網(wǎng)微信公眾號(hào)