Context
- Это приложение Android, работающее по API 29 (с минимальным значением 23).
- Я использую ThirteenTenABP
Проблема
Я просто отлаживаю некоторый код и делаю следующее:
val zonedDateTime = ZonedDateTime.of(
LocalDateTime.of(1900, 1, 1, 15, 15, 0),
ZoneId.of("Europe/Amsterdam"))
Это печатает (toString()
как:
1900-01-01T15:15+00:19:32[Europe/Amsterdam]
Ожидается
Я бы ожидал увидеть 1900-01-01T15:15+02:00:00[Europe/Amsterdam]
или подобное.
Текущее смещение от UT C в Амстердаме составляет +2 из-за перехода на летнее время. Тем не менее, я вижу эти 19 минут и 32 секунды.
Это означает, что если я конвертирую эту зонированную дату и время в UT C используя что-то вроде:
val utcZoned = zonedDateTime.withZoneSameInstant(ZoneOffset.UTC)
Я получаю (в соответствии с ошибкой выше):
1900-01-01T14:55:28Z
Так что это 14 : 55: 28 или что эквивалентно времени 15:15 (15:15) минус 19 минут и тридцать две секунды.
Я что-то здесь упускаю?
Я выполнение этого на эмуляторе. ZoneId.getSystemDefault()
также возвращает тот же ZoneId + Offset. Я начал жестко кодировать Амстердам, чтобы посмотреть, смогу ли я найти разницу.
Другой способ увидеть это, просто выполнив:
* 10 47 *
Результат: ZoneOffset
И в соответствии с указанными выше минутами:
Смещение: +00:19:32
Что я делаю не так Вот?
Пробовал ли я java.time.*
?
Да, я удалил ThirteenTenABP, заменил весь импорт на java.time.*
и запустил его на Android O (8.x), чтобы посмотреть, родные классы времени Java8 дали бы аналогичный результат, и ответ: да.
Смещения происходят из правил смещения:
Но почему эти числа?