TL; DR
Instant parsedBack = Instant.parse(Instant.now().toString());
System.out.println(parsedBack);
2019-05-30T08: 36: 47.966274Z
Используйте ISO 8601 и java.time
- Если вашей реальной целью является сериализация и десериализация даты и времени (например, для передачи данных или для сохранения), сериализация в ISO 8601, стандартный формат для данных даты и времени.
- Пропустить давно устаревший
Date
класс. Современный Java-интерфейс даты и времени, известный как java.time
, гораздо приятнее работать. Вероятно, вам нужен класс Instant
(это зависит от ваших более точных требований).
Два пункта прекрасно сочетаются друг с другом:
Instant i = Instant.now();
String s = i.toString();
Instant theSameInstant = Instant.parse(s);
Методы toString
современных классов создают формат ISO 8601 (например, 2018-01-11T10:59:45.036Z
), а их методы parse
читают тот же формат обратно. Так что этот фрагмент - все, что вам нужно, и вы получите мгновение, равное первому, с точностью до наносекунды.
Если вы не можете контролировать полученную строку и получаете результат из Date.toString()
, строка шаблона формата в ответе BalusC также работает с java.time
:
DateTimeFormatter dtf
= DateTimeFormatter.ofPattern("EEE MMM dd HH:mm:ss zzz yyyy", Locale.ROOT);
Date d = new Date();
String s = d.toString();
Instant nearlyTheSameInstant = ZonedDateTime.parse(s, dtf).toInstant();
Некоторые предупреждения, однако:
- Миллисекунды от первоначального
Date
теряются, поскольку они не находятся в строке, что приводит к неточности до 999 миллисекунд (именно поэтому я назвал переменную nearlyTheSameInstant
).
- Эра из оригинала
Date
также не в строке. Таким образом, если ваш исходный Date
был в 44 году до н.э., вы получите соответствующую дату в 44 году н.э.
- Сокращение часового пояса в строке часто (чаще всего?) Неоднозначно, поэтому существует большой риск получения неправильного часового пояса и, следовательно, неправильного времени. Что еще хуже, неоднозначное сокращение часового пояса будет интерпретироваться по-разному на разных JVM
- Необходимо указать язык. В противном случае будет использоваться языковой стандарт JVM по умолчанию, и если он не будет английским, синтаксический анализ не будет выполнен. В худшем случае вы увидите, что ваш код работает нормально в течение многих лет, и внезапно он сломается, когда однажды кто-нибудь запустит его на компьютере или устройстве с другой настройкой локали. Я использую
Locale.ROOT
для «нейтральной локали» или «не применяю обработку для конкретной локали». Кажется, здесь правильный подход.
Ссылки