Datest, смещения и часовые пояса в java

Question

Я пытаюсь понять базовый механик временных утилит.

Итак, я сделал следующий пример:

public class Test { 
    public static void main(String[] args) { 

     System.out.println(Instant.now().getEpochSecond()); 
     System.out.println(new Date().getTime()); 
     System.out.println(LocalDateTime.now().atZone(ZoneId.systemDefault()).toEpochSecond()); 
     System.out.println(LocalDateTime.now().toEpochSecond(ZoneOffset.UTC)); 

     System.out.println(ZoneId.systemDefault().toString()); 
    } 
} 

Выход есть:

1460651620 
1460651620182 
1460651620 
1460662420 
Europe/Helsinki 

Мой текущий systemDefault ZoneId Европа/Хельсинки (+3 часа)
Когда мы создаем new Date() имеет временная метка unix (UTC).

Это мой базовый пункт, чтобы сравнить печатные результаты.

1. В моей третьей System.out я имею LocalDateTime с установленной временной зоны systemDefault, но выход на самом деле то же самое. Я ожидал большего значения (+3 часа).

2. В четвертой выходной строке я хотя и запутываю результат. Я ожидал того же значения с new Date().getTime()

Нужна помощь, чтобы понять выход.

Answer 1

Любой метод типа getEpochSecond() и toEpochSecond() дает вам количество секунд с момента времени 1970-01-01T00:00:00Z, время работает так же, как и часовой пояс, поэтому результат будет таким же, как и выбранным часовым поясом.

Предполагая, что вы потратили 10 минут, чтобы написать этот вопрос в вашем часовом поясе, это будет то же самое 10 минут в моем часовом поясе.

Answer 2

У меня есть LocalDateTime с установленной временной зоны systemDefault

Нет, вы не знаете. Вы начали с LocalDateTime, но затем вы превратили его в ZonedDateTime. A ZonedDateTime является фактически LocalDateTime с ZoneId и смещением от UTC, чтобы обрабатывать двусмысленность.

LocalDateTime не имеет метода toEpochSecond(), поскольку он не представляет собой фиксированную точку во времени. Он имеет toEpochSecond(ZoneOffset), потому что «привязывает» локальную дату/время к фиксированной точке во времени, применяя смещение UTC.

Сравните с ZonedDateTime, который делает иметь метод без параметров toEpochSecond(), поскольку оно представляет собой неподвижную точку во времени, с дополнительным контексте часового пояса. (Вы можете просмотреть ZonedDateTime как Instant с ZoneId или LocalDateTime с ZoneId и ZoneOffset;. Они эквивалентны, но лично я предпочитаю последнее понятие)

Обратите внимание, что ваш код мог отдавания у вас другой результат - если вы были в период, когда LocalDateTime.now() был неоднозначным из-за возврата часов (как правило, в конце летнего времени). В этом случае LocalDateTime.atZone выбирает более раннее возникновение этого LocalDateTime, тогда как на самом деле вы можете обнаружить .В этом разница между LocalDateTime.now().atZone(zone) и ZonedDateTime.now(zone) - последняя всегда будет «знать» смещение правильно.