Мой вопрос о преобразовании эпохи миллисекунды от даты в заводной - PullRequest
0 голосов
/ 27 июня 2019

Я генерирую метку времени эпохи в миллисекундах с помощью следующего кода, и он работает (проверено с помощью https://www.epochconverter.com/). Однако, когда мы устанавливаем часовой пояс с параметром JVM -Duser.timezone = America / Toronto, то для некоторых исторических дат временисмещение отличается на один час, т. е. дата = 1950-11-19 (гггг-мм-дд), правильная эпоха, миллисекунды -603313200000 (воскресенье, 19 ноября 1950 г., 12:00:00, GMT-05: 00), но когда часовой пояссо значениями параметров JVM -603316800000 и конвертированными эпохами шоу, суббота, 18 ноября 1950 г., 23:00:00 по Гринвичу - 05:00. Я использовал библиотеку joda time с форматом даты JDK 10

def static Long getEpochTimeStampInMilliSeconds(String simpleDate, String dateFormat) {

    Long retVal = null

    try {
        org.joda.time.format.DateTimeFormatter fmt = DateTimeFormat.forPattern(dateFormat)
        DateTimeZone dtz2 = DateTimeZone.forID("America/Toronto")
        DateTime parsedDateTime = DateTime.parse(simpleDate, fmt).withZone(dtz2)
        retVal = parsedDateTime.getMillis()
    } catch (Exception e) {
        retVal = null
    }

    return retVal
}

is: "гггг-мм-дд"

1 Ответ

0 голосов
/ 28 июня 2019

Вам необходимо выполнить синтаксический анализ с правильным часовым поясом, поэтому вместо вызова dateTime.withZone(...) после выполнения синтаксического анализа вам необходимо вызвать dateTimeFormatter.withZone(...) перед анализом с помощью средства форматирования.

Если часовой пояс по умолчанию, установленный системным свойством user.timezone, равен America/Toronto, то проанализированное значение DateTime уже находится в этом часовом поясе, и dateTime.withZone(...) ничего не сделает.

Если часовой пояс по умолчанию является чем-то другим, то проанализированное значение DateTime находится в этом часовом поясе, который будет другим значением миллисекунды эпохи UTC.Вызов dateTime.withZone(...) изменит часовой пояс и, следовательно, значение времени, но не изменит значение миллисекунды эпохи UTC.

def dtz2 = org.joda.time.DateTimeZone.forID("America/Toronto")
def fmt = org.joda.time.format.DateTimeFormat.forPattern(dateFormat).withZone(dtz2)
retVal = org.joda.time.DateTime.parse(simpleDate, fmt).getMillis()

UPDATE

Из комментарий :

Я получаю -603316800000 за 1950-11-19 для всех сценариев, но правильное значение -603313200000

Позволяет проверитькакое значение является правильным, используя Java-Time API:

ZoneId zone = ZoneId.of("America/Toronto");
System.out.println(Instant.ofEpochMilli(-603316800000L));
System.out.println(Instant.ofEpochMilli(-603316800000L).atZone(zone));
System.out.println(Instant.ofEpochMilli(-603313200000L));
System.out.println(Instant.ofEpochMilli(-603313200000L).atZone(zone));

Вывод

1950-11-19T04:00:00Z
1950-11-19T00:00-04:00[America/Toronto]    ⬅ Correct value
1950-11-19T05:00:00Z
1950-11-19T01:00-04:00[America/Toronto]

Как видите, полученное значение (-603316800000) - это правильное значение для 1950-11-19 в полночь по времени Торонто.

Вы получаете смещение -04: 00 для Торонто, потому что в 1950 году летнее время продолжалось до Солнца, 26 ноября в 200:00 (см. https://www.timeanddate.com/time/zone/canada/toronto),, поэтому смещение является корректным для восточного дневного времени (EDT).

Не знаю, почему вы считаете -603313200000 правильным значением, но это не так.

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