Одинаковая временная метка unix в двух регионах, находящихся в одном часовом поясе, дает разные результаты - PullRequest
2 голосов
/ 26 мая 2020

Этот код преобразует datetime в unix timestamp, но у меня другой результат, когда я проверяю результат в Mexico_City и Chica go, которые находятся в одном часовом поясе.

Результат:

Пятница 3 апреля 2020 г. 08:45:18 (am) в часовом поясе Америка / Мехико (CST) и

Пятница 3 апреля 2020 г. 09:45:18 (am) в часовом поясе Америка / Чика go (CDT)

Как решить эту проблему?

https://www.epochconverter.com/timezones?q=1585925118&tz=America%2FMexico_City https://www.epochconverter.com/timezones?q=1585925118&tz=America%2FChicago

DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss")
LocalDateTime dateTime = LocalDateTime.parse(2020-04-03 09:45:18, formatter);
ZoneId zoneId = ZoneId.of("CST", ZoneId.SHORT_IDS)
ZoneOffset zoneOffset = zoneId.getRules.getOffset(LocalDateTime.now)
ldt.toInstant(ZoneOffset.of(String.valueOf(zoneOffset))).toEpochMilli //1585925118000

1 Ответ

0 голосов
/ 26 мая 2020

Не тот часовой пояс

В ваших результатах сказано:

Пятница Апрель 03, 2020 08:45:18 (am) в часовом поясе Америка / Мехико (CST ) и

Пятница Апрель 03, 2020 09:45:18 (am) в часовом поясе America / Chica go (CDT)

Упоминаются два часовых пояса, а не один : Америка / Мехико и Америка / Чика go. Оба часовых пояса имеют одинаковое стандартное смещение от UT C, -06: 00, и оба используют летнее время (летнее время, DST), но это разные часовые пояса.

Ваши результаты верны

В этом году (2020) летнее время началось 8 марта в Америке / Чика go. Итак, в вашем примере дата, 3 апреля, наблюдалось летнее время. Летнее время было , а не в Америке / Мексике в этот день. Там летнее время не начиналось до 5 апреля. Эта разница объясняет, почему в Мексике время было 8:45, а в Чике одновременно - 9:45 go. Используйте ссылки внизу для проверки дат перехода на летнее время в двух часовых поясах.

Что такое часовой пояс?

Часовой пояс, как следует из названия, является зоны на Земле, но концепция также включает в себя исторические c, текущие и известные будущие смещения от UT C, наблюдаемые людьми в этой зоне.

Каждый часовой пояс имеет уникальный идентификатор в * 1023 Формат * регион / город , который также используется в выходных данных из Epoch Converter, который вы использовали.

CST не является часовым поясом. CST - сокращение неоднозначное. Как упоминалось в комментарии, это может относиться к Центральное стандартное время , Стандартное время Кубы или Китайское стандартное время . Вы указали центральное стандартное время, но даже это неоднозначно: оно может относиться к центральному стандартному времени Северной Америки или центральному стандартному времени Австралии. И хотя североамериканское центральное стандартное время уникально и недвусмысленно, это не часовой пояс. Это время, используемое в часовых поясах Америки / Чика go и Америки / Виннипега (и многих других часовых поясов) в течение относительно небольшого числа месяцев в году, когда соблюдается стандартное время. В остальное время года в указанных часовых поясах используется центральное летнее время. Но да, CST также используется в Мехико в течение некоторого времени.

В Java ZoneId.of("CST", ZoneId.SHORT_IDS) дает вам часовой пояс Америки / Чика go, потому что SHORT_IDS определен для этого. Это определение существует только с одной целью: дать вам поведение, совместимое с тем, что дал бы вам давно устаревший класс TimeZone. Если CST не используется в вашей программе по причинам c и не может (легко) быть оставлен, вам не следует использовать ни его, ни SHORT_IDS. Если вам нужен часовой пояс, используйте ZoneId.of("America/Chicago").

Ссылки

...