Многие функции JodaTime оперируют с текущим временным поясом. Это хорошо и для приложения, которое автоматически работает с временем корректно и для разработчика, которому не надо писать эту корректность. Но в юнит-тестах «текущий» временной пояс является неопределённым параметром окружения и может вызывать проблемы.
Например у разработчика, находящегося в зоне UTC+3, такой тест отлично отработает:
1 2 3 4 5 6 7 8 9 | @Test public void testDefaultTimezone() { Instant instant = new Instant(450576000000L); assertThat(instant .toDateTime() .toString("YYYY-MM-dd HH:mm:ss"), is("1984-04-12 03:00:00")); } |
Однако, когда он его загрузит на CI сервер находящийся в зоне UTC+4, тест сломается:
1 2 | testDefaultTimezone(DateTimeSerializerTest) Time elapsed: 0.301 sec <<< FAILURE! org.junit.ComparisonFailure: expected:<1984-04-12 0[3]:00:00> but was:<1984-04-12 0[4]:00:00> |
Чтобы избежать обвинений в сломанном билде, разработчику достаточно будет зафиксировать в тесте временной пояс по умолчанию:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | static private DateTimeZone current; @BeforeClass public static void setUpClass() { current = DateTimeZone.getDefault(); DateTimeZone.setDefault(DateTimeZone.UTC); } @AfterClass public static void tearDownClass() { DateTimeZone.setDefault(current); } @Test public void testDefaultTimezone() { Instant instant = new Instant(450576000000L); assertThat(instant .toDateTime() .toString("YYYY-MM-dd HH:mm:ss"), is("1984-04-12 00:00:00")); } |
DateTimeZone.setDefault() меняет временной пояс по умолчанию только для JodaTime объектов, не затрагивая временной пояс всей jvm.
