4 回答

TA貢獻1815條經(jīng)驗 獲得超6個贊
當(dāng)您創(chuàng)建新日歷時,它包含當(dāng)前日期和時間。之后,您更新除毫秒之外的所有字段。如您所見,所有輸出中只有最后 3 個數(shù)字不同,這是執(zhí)行時間的毫秒數(shù)。

TA貢獻1828條經(jīng)驗 獲得超3個贊
java.time
ZoneId zone = ZoneId.of("Europe/Brussels");
ZonedDateTime start2018 = LocalDate.of(2018, Month.JANUARY, 1).atStartOfDay(zone);
Instant asInstant = start2018.toInstant();
System.out.println(asInstant.toEpochMilli());
這始終提供以下輸出:
1514761200000
如果不是歐洲/布魯塞爾,請?zhí)鎿Q您想要的時區(qū)。
格式化輸出:
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy/MM/dd HH:mm:ss");
System.out.println(start2018.format(formatter));
2018/01/01 00:00:00
您使用的日期和時間類 — SimpleDateFormat、Calendar和GregorianCalendar—Date都設(shè)計不佳且早已過時。SimpleDateFormat特別是出了名的麻煩,但在這種情況下,正是糟糕的設(shè)計Calendar給了你意想不到的結(jié)果。其他答案已經(jīng)解釋了如何,我就不用重復(fù)了。我建議您使用現(xiàn)代 Java 日期和時間 API java.time,而不是舊類。與它一起工作要好得多。

TA貢獻1868條經(jīng)驗 獲得超4個贊
在時間戳中,最后 3 位數(shù)字代表毫秒。在這里,您明確設(shè)置了日期和時間,但沒有設(shè)置毫秒。這就是你面對這個的原因。為避免這種情況,您可以將其添加到您的代碼中:
calendar.set(Calendar.MILLISECOND, 0);

TA貢獻1780條經(jīng)驗 獲得超4個贊
我假設(shè)您正在示例中的循環(huán)中實例化所有內(nèi)容?
如果是這樣,則您沒有設(shè)置毫秒差異,因此它們在循環(huán)的每次迭代中都會發(fā)生變化(但略有變化)。
為避免這種情況,您可以設(shè)置毫秒數(shù),或在循環(huán)外進行實例化:
SimpleDateFormat sdf = new SimpleDateFormat("yyyy/MM/dd HH:mm:ss");
Calendar calendar = new GregorianCalendar();
calendar.set(2018, 0, 1, 0, 0, 0);
for (int i = 0; i < 5; i++) {
System.out.println(sdf.format(calendar.getTime()));
Date date = calendar.getTime();
System.out.println(sdf.format(date));
System.out.println(date.getTime());
}
這將產(chǎn)生:
2018/01/01 00:00:00
2018/01/01 00:00:00
1514764800128
2018/01/01 00:00:00
2018/01/01 00:00:00
1514764800128
2018/01/01 00:00:00
2018/01/01 00:00:00
1514764800128
2018/01/01 00:00:00
2018/01/01 00:00:00
1514764800128
2018/01/01 00:00:00
2018/01/01 00:00:00
1514764800128
添加回答
舉報