Этот вопрос довольно близок к моему, однако я нахожу ответ не подходящим для меня.У меня есть метка времени Long.
ts = 1362156863140L
Поскольку она длинная, я считаю ее наивной временной меткой, верно?Время по местному времени в Кельне - UTC + 0200 (CET).Поэтому, когда я конвертирую его в метку времени, соответствующую строковому часовому поясу, я хочу получить:
2013-03-01T14:54:23.140Z
или
2013-03-01T16:54:23.140+02:00
Я использую решение из ответа в начале моего вопроса:
Instant.ofEpochMilli(timestamp).atOffset(ZoneOffset.of("+2"));
, который возвращает:
2013-03-01T18:54:23.140+02:00
другой часовой пояс:
Instant.ofEpochMilli(timestamp).atOffset(ZoneOffset.of("Z"));
возвращает:
2013-03-01T16:54:23.140Z
Таким образом, эти методы на самом деле не изменяютчасовой пояс, они просто меняют представление метки времени.Я также попробовал другой метод:
OffsetDateTime.ofInstant(Instant.ofEpochMilli(timestamp), ZoneId.of("UTC"));
Но результаты точно такие же. Это решение было полезным, но оригинальным подходом:
int offset = TimeZone.getTimeZone("Europe/Amsterdam").getRawOffset();
long newTime = timestamp - offset;
не учитывает летнее / зимнее время.И предлагаемые ответы используют класс Calendar, который устарел для JDK8.Что работает и достаточно очевидно:
OffsetDateTime.ofInstant(Instant.ofEpochMilli(Timestamp), ZoneId.of("UTC")).minusSeconds(7200);
Но это определенно неправильный способ сделать это, так как я могу сделать это с часовым поясом?