конвертировать из миллис с Epoch в LocalDateTime в Java 10 против Java 8 - PullRequest
Новая
       38

конвертировать из миллис с Epoch в LocalDateTime в Java 10 против Java 8

0 голосов
/ 07 сентября 2018

У меня есть приложение, где я использую миллисекунды с Epoch для преобразования в LocalDateTime и обратно, приложение работало хорошо на Java 8, но я попытался обновить Java 10 и обнаружил следующую проблему

Это вывод в Java 8 

 ✘ magg@MacBook-Pro-de-Miguel  ~/Desktop/CODE  java TimeTest
2018-09-06T20:13:30.253
1536290010253
2018-09-06T20:13:30.253
 ✘ magg@MacBook-Pro-de-Miguel  ~/Desktop/CODE  java -version
java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)

Это вывод в Java 10, если вы видите формат длиной 6 цифр в конце, а не три, как в Java 8, и это прерывает преобразование из миллисекунд с Epoch в LocalDateTime 

✘ magg@MacBook-Pro-de-Miguel  ~/Desktop/CODE  java TimeTest
2018-09-06T20:13:18.568414
1536289998568
2018-09-06T20:13:18.568
 ✘ magg@MacBook-Pro-de-Miguel  ~/Desktop/CODE  java -version
java version "10.0.2" 2018-07-17
Java(TM) SE Runtime Environment 18.3 (build 10.0.2+13)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode)

Вот исходный код 

public class TimeTest{


public static void main(String[] args)
{

TimeZone.setDefault(TimeZone.getTimeZone("America/Los_Angeles"));

LocalDateTime issueTime = LocalDateTime.now();

System.out.println(issueTime.toString());

ZonedDateTime zdt = issueTime.atZone(TimeZone.getDefault().toZoneId());
long timeInMillis = zdt.toInstant().toEpochMilli();
System.out.println(timeInMillis );

LocalDateTime date = LocalDateTime.ofInstant(Instant.ofEpochMilli(timeInMillis), TimeZone.getDefault().toZoneId());

System.out.println(date.toString());
}
}

Как я могу это исправить в Java 10?

1 Ответ

0 голосов
/ 07 сентября 2018

Во-первых, вывод из LocalDateTime.toString() не имеет фиксированной длины. От его Javadoc (который не изменяется с 8 до 10): 

public String toString()
Outputs this date-time as a String, such as 2007-12-03T10:15:30.
The output will be one of the following ISO-8601 formats:

uuuu-MM-dd'T'HH:mm
uuuu-MM-dd'T'HH:mm:ss
uuuu-MM-dd'T'HH:mm:ss.SSS
uuuu-MM-dd'T'HH:mm:ss.SSSSSS
uuuu-MM-dd'T'HH:mm:ss.SSSSSSSSS
The format used will be the shortest that outputs the full value of the time where the omitted parts are implied to be zero.

Ваш прогон Java 10 случайно напечатал значение секунд с шестью десятичными разрядами, но, возможно, он напечатал его с тремя десятичными или девятью десятичными знаками в зависимости от пары факторов:

  • Часы компьютера, которые могут или не могут быть способны к наноточной точности.
  • Фактическое значение, возвращаемое now().

Статистически маловероятно, но определенно возможно, что это можно выразить, используя только три десятичных знака вместо шести. И гораздо более вероятно, что для поддержки этого оборудования потребуется девять знаков после запятой, а не шесть. Когда я запускал ваш код под Java 10, обычно печаталось девять знаков после запятой, но иногда требовалось только шесть.

Во-вторых, в Java 9 "системные часы, возвращаемые java.time.Clock" , были изменены ", так что они предлагают, по крайней мере, ту же точность, что и базовые часы, доступные в системе" . См. JDK-8068730 Увеличьте точность реализации java.time.Clock.systemUTC () , которая явно обращается к вашей ситуации:

Приложение, предполагающее, что часы вернули эти методы фабрики системы всегда будут иметь точность в миллисекунды и активно зависит от него, поэтому, возможно, потребуется обновить, чтобы учитывать возможность большего разрешения ...

Что касается вашего вопроса «Как я могу это исправить в Java 10?» , я не уверен, что вы хотели бы исправить, так как я не знаю деталей требований вашего приложения .

Комментарий от teppic уже объяснял, как вы можете ограничить точность до трех десятичных знаков, используя LocalDateTime.now().truncatedTo(ChronoUnit.MILLIS), но я не вижу преимущества в этом, если у вас нет требований к приложению для фиксированная точность трех знаков после запятой. Альтернативным подходом может быть использование нано-точности и нуля до девяти цифр при необходимости; тогда вы получите преимущество большей точности, но при этом будете иметь фиксированные значения длины.

...