Различение и разбор дат в Java

Question

я знаю, что эта тема не нова, хотя мне нужно снова ее выкопать.Я уже много раз искал в Интернете (включая некоторые потоки здесь на stackoverflow), но до сих пор не нашел удовлетворительного ответа.

(Среди прочих я проверил Анализ неоднозначных дат в Java и http://www.coderanch.com/t/375367/java/java/Handling-Multiple-Date-Formats-Elegantly

В настоящее время я пишу Dateparser в Java, который берет дату и генерирует формат-Строка, которая может использоваться SimpleDateFormat для синтаксического анализа даты.

Даты анализируются с помощью регулярных выражений (да, это безобразный xD) из файлов журналов (IBM Websphere, Tomcat, Microsoft Exchange, ....).Поскольку у нас есть клиенты в (как минимум 2) разных локалях, невозможно просто «перебросить» строку в метод синтаксического анализа SimpleDateFormat и ожидать, что она будет работать правильно.

Кроме того, существует проблемас позицией дня и месяца (т. е. форматов «дд / мм / гггг» или «мм / дд / гггг»), которые невозможно решить, если у меня нет хотя бы двух наборов данных, в которых изменилась цифра дня ..

Таким образом, мой текущий подход будет хранить форматы даты для определенного программного обеспечения, установленного на системах конкретного клиента, в базе данных (mysql / xml / ...) и заставлять пользователя по крайней мереукажите имя клиента и имя программного обеспечения, чтобы было достаточно контекста, чтобы разбить количество возможных вариантов, в которых может быть указан формат.

Этот «подмножество» затем будет использоваться для попытки анализа файлов журнала указанного программного обеспечения.(Подмножество хранится в HashMap в HashMap в форме HashMap> map; Integer-Key - длина строки format, а String Key второго Hashmap задает сигнатуру даты, содержащую только разделяющие символы. (Т. Е. "..::. "для даты в формате" dd.MM.yyyy 11: 11: 11.111 ")

Я также принимаю во внимание значение цифр, то есть цифра> 12 должна быть днем, потому что13-го месяца нет, но это надежно работает только для строк дат после 12-го числа месяца.

Есть ли шанс избежать применения предварительных знаний об окружающей среде, из которой поступил лог-файл, таким образомпозволить анализатору надежно проанализировать одну дату без необходимости ссылаться на вторую строку даты для сравнения?

Я застрял на этом уже почти 3 месяца -.-

Любые предложения будут приветствоваться=)

Редактировать:

Хорошо, ребята, эта тема может быть закрыта.Теперь я нашел другое решение для моей конкретной проблемы.Для тех, кому интересно: пишу Logreader на Java.Поскольку у нас есть регулярное обслуживание, я должен прочитать много лог-файлов.Но это не просто текстовая информация, которая записана в файле.Представьте себе, что сервер только что вышел из строя, это воскресная ночь, и следующий человек, который заметит, - глава ИТ-отдела клиента.Затем на следующий день я должен провести техническое обслуживание и проверить файлы журналов.Судя по содержанию, все казалось нормально, ничего необычного.Через полчаса после отправки отчета о техническом обслуживании я получаю письмо с указанным выше заголовком, что сервер вышел из строя и, похоже, остался незамеченным.

Дело в том, что вы не можете отслеживать содержимое и метки времени для файлов журналов с несколькими тысячами строк.Поэтому я разработал компонент, который читает файл журнала и вычисляет время между двумя различными записями журнала.Каждый лог-файл анализировался в java.util.Date, чтобы позже получить Date as Timestamp для высокого разрешения относительно интервалов регистрации.Различия, которые я затем бросил в линейный граф, который делает более длительные тайм-ауты между двумя лог-линиями видимыми как большой всплеск, относящийся к остальной части файла.

Мое решение теперь будет состоять в том, чтобы полностью отбросить половину даты в строке и вставить фиктивную дату в предопределенном формате.Дата должна измениться только при приближении Часа и минуты к 23:59.Первоначальная дата позже представлена ​​на графике с «поддельными данными», лежащими внизу.

Благодарю всех вас за ваши предложения и отзывы =) (И я надеюсь, что мой английский до сих пор понятен;))

Answer 1

Мое предложение состоит в том, чтобы хранить все даты как «неоднозначные» до тех пор, пока неоднозначность не будет устранена. (Это предполагает, что конкретный клиент всегда будет предоставлять данные в одном и том же формате.) Как только вы получите журнал от клиента, для которого вы можете однозначно определить формат даты, вы сможете ретроспективно применить этот формат к предыдущим файлам. .

Чтобы сделать это, вам понадобится таблица, отображающая каждого клиента в его формат даты с некоторым маркером (например, NULL), чтобы указать, что формат еще не установлен. Возможно, вам также потребуется создать собственное представление даты, чтобы вы могли смоделировать эти неоднозначные даты.

Так, например, если возможные форматы даты:

dd/mm/yyyy
mm/dd/yyyy
yyyy/mm/dd
yyyy/dd/mm

Учитывая даты, вы всегда должны иметь возможность идентифицировать год (разрешение двухзначного года значительно усложнит эту проблему). Таким образом, вы должны иметь возможность отображать даты следующим образом:

25/01/2011 -> UNAMBIGUOUS_DD_MM_YYYY
12/01/2011 -> AMBIGUOUS_XX_XX_YYYY
2011/03/03 -> AMBIGUOUS_YYYY_XX_XX
03/30/2011 -> UNAMBIGUOUS_MM_DD_YYYY

Answer 2

Я думаю, что стратегия, к которой вы стремитесь (то есть анализ большего набора данных) - это лучшее, что вы можете получить. Из одной строки лог-файла вы никогда не узнаете, является ли 3/5/11 3 мая 2011 года или 5 марта 2011 года. (Я полагаю, также могут быть локали, которые могут интерпретировать это как 11 мая 2003 года. ..) У меня были такие проблемы некоторое время назад, и я также мог только попытаться представить какой-то контекст, либо посмотрев на числа> 12, либо на то, что меняется быстрее всего (должно быть, «день»). Но вы уже заявили, что сами ...

Answer 3

Если возможно, вы можете попросить клиентов передать строку dateformat вместе с их фактическими строками даты.

то есть в своих файлах журналов им потребуется еще один столбец

....., '03 / 11/2011 ',' MM / DD / YYYY ', ...