Java: временная метка неверна
Я получил временную метку ошибки
try {
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss");
LocalDateTime localDateTime = LocalDateTime.parse("1991-04-14 10:30:00", formatter);
ZoneId zoneId = ZoneId.systemDefault();
ZonedDateTime zdt = localDateTime.atZone(zoneId);
Instant instant = zdt.toInstant();
System.out.println(instant.toEpochMilli());
} catch (DateTimeParseException e) {
e.printStackTrace();
}
печать => 671592600000
Но MYSQL получил другое значение
SELECT FROM_UNIXTIME(671592600000/1000);
результат 1991-04-14 09:30:00.0000
часовой пояс = +8.00
Ответы 1
Вы смешиваете часовые пояса.
Предположительно, «UNIXTIME» в вашей строке кода SQL относится к Unix-время, которое отслеживается как количество секунд или миллисекунды (или какая-то подобная степень детализации) с ссылка на эпоху первого момента 1970 года в формате UTC. ⬅ Эта часть универсальное глобальное время имеет решающее значение.
Ваш Java-код взял объект LocalDateTime и поместил его в контекст некоторого (неизвестного нам здесь) часового пояса. Так что, конечно, результаты разные.
Вы должны были поместить эту входную строку в контекст UTC (смещение от UTC, равный нулю).
LocalDateTime // Represent a date with a time-of-day. But lacking any concept of time zone or offset-from-UTC, this does *NOT* represent a moment, is *NOT* a point on the timeline.
.parse(
"1991-04-14 10:30:00"
.replace( " " , "T" ) // Replace SPACE in middle with `T` to comply fully with ISO 8601 standard format.
) // Returns a `LocalDateTime` object.
.atOffset( // Give meaning to the `LocalDateTime` by determining a moment with the context of an offset-from-UTC.
ZoneOffset.UTC // A constant for UTC (an offset of zero).
) // Returns an `OffsetDateTime` object.
.toInstant() // Convert from the more flexible `OffsetDateTime` to the basic building-block class of `Instant`. An `Instant` is *always* in UTC, by definition.
.toEpochMilli() // Returns a `long`, a count of milliseconds since 1970-01-01T00:00:00Z. Beware possible data-loss as any microseconds or nanoseconds will be ignored when counting in milliseconds.
Вы должны четко понимать, что LocalDateTimeнет представляет собой момент, а нет — это точка на временной шкале. Когда вы сказали 10:30 утра 14 апреля, это может быть утро в Токио, Париже или Монреале, все разные моменты. Без контекста зоны или смещения LocalDateTime не имеет реального значения. См.: В чем разница между Instant и LocalDateTime?
@ CN.CHAO-LI Похоже, ваш часовой пояс не имеет отношения к этой ситуации. Вы должны работать только в UTC, если я правильно прочитал ваше описание проблемы.
3Q! Я должен сказать «КРУТО», но я говорю «666666666» по-китайски.
Спасибо за тебя! Часовой пояс среды выполнения Java — Азия/Шанхай.