System.currentTimeMillis () против Timestamp.valueOf (LocalDateTime.now (UT C)). GetTime () - PullRequest
0 голосов
/ 11 февраля 2020

Не оба System.currentTimeMillis() vs Timestamp.valueOf(LocalDateTime.now(UTC)).getTime() предположим, чтобы дать одно и то же число, попробуйте и выясните, что это не так.

В чем причина этого, разве не предполагается, что оба дают одинаковое число ie нет milise c с 1970 года?

1 Ответ

2 голосов
/ 11 февраля 2020

Если вы прочитали документацию , javado c из Timestamp.valueOf​(LocalDateTime dateTime) говорит:

Предоставленный LocalDateTime интерпретируется как местное время и дата в местном часовом поясе .

Начиная с LocalDateTime в UT C часовом поясе, а не местный часовой пояс, результатом является сдвиг часового пояса к часовому поясу JVM по умолчанию. Если вы удаляете ZoneOffset.UTC из вызова now() или используете вместо него ZoneId.systemDefault(), он будет работать так, как вы ожидали.

В качестве альтернативы, если у вас есть LocalDateTime в UT C, и хотите преобразовать в Timestamp, вам нужно сказать, что LocalDateTime в UT C:

LocalDateTime ldt = LocalDateTime.now(UTC); // cannot change time zone
long millis = Timestamp.from(ldt.atZone(UTC).toInstant()).getTime(); // so specify time zone

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...