您尝试使用的Calendar类总是设计不佳，现在已经过时了.取而代之的是，我按照其中的建议，我使用的是java.time，这是现代的Java日期和时间API.为了进行比较，Calendar具有毫秒级的分辨率，因此充其量只会给您带来精度上的隐患.更精确的数学我不能让85纳秒成为现实.这是一个尽可能保持精度并提供预期结果的版本: BigDecimal timeStamp = new BigDecimal(new BigInteger("C50204ECEC42EE92", 16)); // To get the whole part and the fraction right, divide by 2^32 BigDecimal bit32 = new BigDecimal(0x1_0000_0000L); BigDecimal secondsSince1900 = timeStamp.divide(bit32); // Convert seconds to nanos by multiplying by 1 000 000 000; round to long long nanosSince1900 = secondsSince1900.multiply(new BigDecimal(TimeUnit.SECONDS.toNanos(1))) .setScale(0, RoundingMode.HALF_UP) .longValueExact(); Instant converted = epoch.plusNanos(nanosSince1900); 1纳米太多吗?这是因为我在对setScale的调用中使用了上舍入四舍五入.相反，如果我截断(使用RoundingMode.FLOOR)，则可以从解释中获得确切的结果.因此，我的版本不会比他们的版本失去更多的精度.链接 Oracle教程:日期时间解释了如何使用java.time./p>I have been trying to figure out how to convert a timestamp to a date but with the trailing decimals at the end, so for example:Timestamp - C50204EC EC42EE92 is equivalent to Sep 27, 2004 03:18:04.922896299 UTC.The timestamp format includes the first 32-bit unsigned seconds as a field spanning 136 years and the 32-bit fraction field resolving 232 picoseconds. In the timestamp formats, the prime epoch, or base date of era 0, is 0 h 1 January 1900 UTC, when all bits are zero.This is what I have written for my code so far: BigDecimal bi = new BigDecimal("1096255084000"); double decimal_timestamp = bi.doubleValue(); DateFormat formatter = new SimpleDateFormat("dd/MM/yyyy hh:mm:ss.SSS"); formatter.setTimeZone(TimeZone.getTimeZone("UTC")); Calendar calendar = Calendar.getInstance(); calendar.setTimeInMillis(decimal_timestamp); String date = formatter.format(calendar.getTime()); System.out.println(decimal_timestamp + " = " + date);My thought is that it is probably not possible with calendar, so I'll have to do it from scratch, but I have no idea how to go about doing that. 解决方案 java.timeUsing the example from the explanation: Instant epoch = OffsetDateTime.of(1900, 1, 1, 0, 0, 0, 0, ZoneOffset.UTC).toInstant(); BigInteger timeStamp = new BigInteger("C50204ECEC42EE92", 16); // To get the whole part and the fraction right, divide by 2^32 double secondsSince1900 = timeStamp.doubleValue() / 0x1_0000_0000L; // Convert seconds to nanos by multiplying by 1 000 000 000 Instant converted = epoch.plusNanos(Math.round(secondsSince1900 * 1_000_000_000L)); System.out.println(converted);Output is:It’s off by 85 nanoseconds. Likely better floating-point arithmetic can do even better. Edit: A little loss of precision is unavoidable since the original time stamp has a resolution of 2^-32 seconds, which is more than 4 times as fine as the nanosecond (10^-9 second) resolution of Instant.The Calendar class that you were trying to use was always poorly designed and is now long outdated. Instead I do as Amongalen suggested in a comment, I am using java.time, the modern Java date and time API. Edit: For comparison Calendar has millisecond resolution, so would at best give you a substabtial loss of precision.Edit: More precise mathI couldn’t let the 85 nanoseconds be. Here’s a version that preserves precision as far as possible and gives the expected result: BigDecimal timeStamp = new BigDecimal(new BigInteger("C50204ECEC42EE92", 16)); // To get the whole part and the fraction right, divide by 2^32 BigDecimal bit32 = new BigDecimal(0x1_0000_0000L); BigDecimal secondsSince1900 = timeStamp.divide(bit32); // Convert seconds to nanos by multiplying by 1 000 000 000; round to long long nanosSince1900 = secondsSince1900.multiply(new BigDecimal(TimeUnit.SECONDS.toNanos(1))) .setScale(0, RoundingMode.HALF_UP) .longValueExact(); Instant converted = epoch.plusNanos(nanosSince1900);1 nano too much? This is because I used half-up rounding in the call to setScale. If instead I truncate (using RoundingMode.FLOOR), I get the exact result from the explanation. So my version doesn’t lose more precision than theirs.LinkOracle tutorial: Date Time explaining how to use java.time. 这篇关于如何在Java中使用尾随小数点将十进制时间戳转换为日期的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 上岸，阿里云！
