как разобрать вывод новой Date (). toString () - PullRequest
22 голосов
/ 17 января 2011

Мне нужен формат даты (может быть SimpleDateFormat), который надежно анализирует выходные данные, которые я получаю, когда вызываю toString () для объекта Date.Вывод моей немецкой (!) Системы: «Sun Dec 12 13:45:12 CET 2010», так что, похоже, он не учитывает локали, что, кажется, облегчает.

Любой?

Ответы [ 3 ]

28 голосов
/ 17 января 2011

Этот формат указан в Date#toString().

Преобразует этот Date объект в String формы:

dow mon dd hh:mm:ss zzz yyyy

Итак, в SimpleDateFormat шаблонных терминах:

EEE MMM dd HH:mm:ss zzz yyyy

Не имеет отношения к проблеме. Интересно, не плохая ли идея использовать Date#toString() вместо SimpleDateFormat#format() для вывода дат. Я хотел бы исправить это прямо там.

6 голосов
/ 17 января 2011

BalusC дал вам правильный формат, вы бы сказали - нет.Метод toString() нельзя использовать ни для чего, кроме ведения журнала.

Вы можете использовать SimpleDateFormat для форматирования и анализа.

1 голос
/ 30 мая 2019

TL; DR

    Instant parsedBack = Instant.parse(Instant.now().toString());
    System.out.println(parsedBack);

2019-05-30T08: 36: 47.966274Z

Используйте ISO 8601 и java.time

  1. Если вашей реальной целью является сериализация и десериализация даты и времени (например, для передачи данных или для сохранения), сериализация в ISO 8601, стандартный формат для данных даты и времени.
  2. Пропустить давно устаревший 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();

Некоторые предупреждения, однако:

  1. Миллисекунды от первоначального Date теряются, поскольку они не находятся в строке, что приводит к неточности до 999 миллисекунд (именно поэтому я назвал переменную nearlyTheSameInstant).
  2. Эра из оригинала Date также не в строке. Таким образом, если ваш исходный Date был в 44 году до н.э., вы получите соответствующую дату в 44 году н.э.
  3. Сокращение часового пояса в строке часто (чаще всего?) Неоднозначно, поэтому существует большой риск получения неправильного часового пояса и, следовательно, неправильного времени. Что еще хуже, неоднозначное сокращение часового пояса будет интерпретироваться по-разному на разных JVM
  4. Необходимо указать язык. В противном случае будет использоваться языковой стандарт JVM по умолчанию, и если он не будет английским, синтаксический анализ не будет выполнен. В худшем случае вы увидите, что ваш код работает нормально в течение многих лет, и внезапно он сломается, когда однажды кто-нибудь запустит его на компьютере или устройстве с другой настройкой локали. Я использую Locale.ROOT для «нейтральной локали» или «не применяю обработку для конкретной локали». Кажется, здесь правильный подход.

Ссылки

...