Observe este método para ver quais campos são suportados. Você encontrará por LocalDateTime
:
•NANO_OF_SECOND
•NANO_OF_DAY
•MICRO_OF_SECOND
•MICRO_OF_DAY
•MILLI_OF_SECOND
•MILLI_OF_DAY
•SECOND_OF_MINUTE
•SECOND_OF_DAY
•MINUTE_OF_HOUR
•MINUTE_OF_DAY
•HOUR_OF_AMPM
•CLOCK_HOUR_OF_AMPM
•HOUR_OF_DAY
•CLOCK_HOUR_OF_DAY
•AMPM_OF_DAY
•DAY_OF_WEEK
•ALIGNED_DAY_OF_WEEK_IN_MONTH
•ALIGNED_DAY_OF_WEEK_IN_YEAR
•DAY_OF_MONTH
•DAY_OF_YEAR
•EPOCH_DAY
•ALIGNED_WEEK_OF_MONTH
•ALIGNED_WEEK_OF_YEAR
•MONTH_OF_YEAR
•PROLEPTIC_MONTH
•YEAR_OF_ERA
•YEAR
•ERA
O campo INSTANT_SECONDS - é claro - não é suportado porque um LocalDateTime
não pode se referir a nenhum carimbo de data / hora absoluto (global). Mas o que é útil é o campo EPOCH_DAY que conta os dias decorridos desde 01-01-1970. Pensamentos semelhantes são válidos para o tipo LocalDate
(com campos ainda menos suportados).
Se você pretende obter o campo millis-since-unix-epoch não existente, você também precisa do fuso horário para converter de um tipo local em global. Essa conversão pode ser feita de maneira muito mais simples, consulte outros posts do SO .
Voltando à sua pergunta e aos números em seu código:
The result 1605 is correct
=> (2014 - 1970) * 365 + 11 (leap days) + 31 (in january 2014) + 3 (in february 2014)
The result 71461 is also correct => 19 * 3600 + 51 * 60 + 1
16105L * 86400 + 71461 = 1391543461 segundos desde 1970-01-01T00: 00: 00 (atenção, sem fuso horário) Então, você pode subtrair o deslocamento do fuso horário (cuidado com a possível multiplicação por 1000 se em milissegundos).
ATUALIZAR após determinadas informações de fuso horário:
local time = 1391543461 secs
offset = 3600 secs (Europe/Oslo, winter time in february)
utc = 1391543461 - 3600 = 1391539861
Como código JSR-310 com duas abordagens equivalentes:
long secondsSinceUnixEpoch1 =
LocalDateTime.of(2014, 2, 4, 19, 51, 1).atZone(ZoneId.of("Europe/Oslo")).toEpochSecond();
long secondsSinceUnixEpoch2 =
LocalDate
.of(2014, 2, 4)
.atTime(19, 51, 1)
.atZone(ZoneId.of("Europe/Oslo"))
.toEpochSecond();