Тестирование парсера даты с часовым поясом в Java

1

То, что кажется довольно простой проблемой, дает мне серьезную головную боль при синтаксическом анализе даты.

В моем проекте java у меня есть собственный класс анализатора даты, который обрабатывает все различные разновидности форматов строки даты, с которыми он может столкнуться.

Недавно мне пришлось добавить следующий прецедент: 

DateFormat fileDateImport = new SimpleDateFormat("EEE, dd MMM yyyy hh:mm:ss zzz");<br />
return fileDateImport.parse(stringToParse);

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

Date returnDate = DateParser.parseDate("Wed, 24 Sep 2014 00:00:00 BST");
final SimpleDateFormat convertedTime = new SimpleDateFormat("ddMMyyyyhhmmss");
convertedTime.setTimeZone(TimeZone.getTimeZone("BST"));
assertEquals("24092014000000", convertedTime.format(returnDate));

Объект returnDate читает "Вт Сен 23 18:00:00 CDT 2014", что я и ожидал. CST - 6 часов по сравнению с BST. Тем не менее, я не хочу проверять toString() этой даты, так как этот тест может потенциально запускаться в разных часовых поясах.

Конечным результатом формата является "24092014050000". Я не уверен, как это получилось в то время, оно ускоряется 11 часов от исходного returnDate.

Я попытался установить время returnDate в календарном объекте, но получаю тот же результат.

Кто-нибудь, более удобный, с датами, чем у меня, есть идеи?

  • 0
    Если вы можете использовать Java 8, была представлена гораздо лучшая модель Date, ищите ZonedDateTime . Тем временем помните, что BST = GMT + 1.
  • 0
    Это приятно знать, но, к сожалению, я не могу это контролировать! Наша текущая версия Java - 7.
Показать ещё 1 комментарий
Теги:
junit
date-parsing

2 ответа

2
Лучший ответ

Кажется, вам придется использовать "Европа/Лондон" вместо "BST", если вы имеете в виду британское стандартное время (или "Азия/Дакка", если вы имеете в виду стандартное время Бангладеш).

 convertedTime.setTimeZone(TimeZone.getTimeZone("Europe/London"));

См. Http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4257424

Поделиться
  • 0
    Спасибо Джованни, что сделал свое дело! И это объясняет разницу во времени в 11 часов, должно быть, это было стандартное время Бангладеш.
3

Если я понимаю ваш вопрос, одним из решений является вызов setTimeZone() в вашем convertedTime DateFormat и передача результата getTimeZone() из fileDateImport DateFormat fileDateImport DateFormat. То есть, что-то вроде -

DateFormat fileDateImport =new SimpleDateFormat("EEE, dd MMM yyyy HH:mm:ss zzz");
try {
    Date d = fileDateImport.parse("Wed, 24 Sep 2014 00:00:00 BST");
    final SimpleDateFormat convertedTime =new SimpleDateFormat("ddMMyyyyHHmmss");
    convertedTime.setTimeZone(fileDateImport.getTimeZone());
    if ("24092014000000".equals(convertedTime.format(d))) {
        System.out.println("Passed");
    } else {
        System.out.println("Failed");   
    }
} catch (ParseException e) {
    e.printStackTrace();
}

Какие выходы Passed потому что они проходят ваш unit тест. Основные отличия - использование TimeZone от парсера (и использование HH вместо hh течение нескольких часов).

Поделиться
  • 0
    -1 ОП показывает, что он вызывает setTimeZone с нужным часовым поясом BST . Часовой пояс fileDateInport является CST как было указано.
  • 0
    @JohnB За исключением того, что если вы запустите код выше, он пройдет модульный тест, который опубликовал OP. Обратите внимание, что я использую HH вместо hh в строке формата. Кроме того, однако, я не хочу проверять на соответствие toString () этой даты, поскольку этот тест может потенциально выполняться в разных часовых поясах.
Показать ещё 5 комментариев

Ещё вопросы

Сообщество Overcoder
Наверх
Меню