смешение часовых поясовСдвиг почти на 2 часа для двух временных меток, предположительно удерживающих часовой пояс UTC

Question

Я использую код:

import java.time.LocalDateTime
import java.time.ZoneOffset
import java.time.format.DateTimeFormatter
var formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSS")
LocalDateTime.now(ZoneOffset.UTC).format(formatter)
LocalDateTime.now().format(formatter)

для создания метки времени события в формате UTC в приложении для Android.

Пример вывода может быть:

2019-09-30T19:19:49.133 # the app (UTC)
2019-09-30T21:19:49.398 # my current time zone

Теперь, когда вы отправляете его в облачное хранилище сообщений (Azure Event Hub), добавляется одно поле с временем отправки в UTC (enqueuedtimeutc, https://docs.microsoft.com/en-us/dotnet/api/microsoft.azure.eventhubs.eventdata.systempropertiescollection.enqueuedtimeutc?view=azure-dotnet)

Однако при расчете расстояния между двумя смещениями почти 2 часаобе временные метки предположительно доставляются в UTC:

distance(s)  frequency
7194.0    0.350518
7196.0    0.133110
7195.0    0.084421
7199.0    0.077668
7193.0    0.075642

как это можно объяснить? Я подумал, что обе метки времени в UTC. И на самом деле вывод в примере выглядит нормально.

Часы на моем устройстве Android отключены на 2 часа (также маловероятно, поскольку смартфоны обычно синхронизируются с часами). Почему разница во времени не точно равна 2hours * 60minuts * 60seconds = 7200 seconds, а меньше? Поскольку необходимо добавить задержку и время обработки, я ожидаюэто значение должно быть больше.

edit

Может быть, лучше использовать:

DateTimeFormatter.ISO_INSTANT.format(Instant.now())

Но это не должно ничего менять, то есть точно (кроме формата stкольцо) в соответствии с моим выходным временем.

Answer 1

Я думал, что обе метки времени в UTC.

Не совсем.

Никогда не звоните LocalDateTime.now. Я не могу представить случай, когда это имеет смысл. Конечно, не в этом случае.

В этом классе отсутствует понятие часового пояса или смещения от UTC. Поэтому его нельзя использовать для отслеживания момента. LocalDateTime содержит только дату и время суток. Так что если вы фиксируете текущий полдень 23 января 2020 года в America/Montreal с помощью LocalDateTime, вы просто выбросили информацию о Монреале. Так что у нас остались только дата и время суток. Мы больше не знаем, имели ли вы в виду полдень в Токио, Япония, полдень в Тунисе, Тунис или полдень в Лос-Анджелесе, штат Калифорния, США - все это очень разные моменты, за исключением нескольких наших, и ни один из них не является вашим первоначальным намерением. Мы потеряли ваше первоначальное намерение.

Вы сделали захватили дату и время суток, как показано в UTC, пропустив ZoneOffset.UTC, но использование LocalDateTime не добавляет значения, только отвлечениеили, возможно, непреднамеренные значения.

Instant

Чтобы зафиксировать текущий момент в UTC, используйте Instant.

Instant instant = Instant.now() ;  // Capture the current moment as seen in UTC.

ISO 8601

Стандартный способ представлениятакое значение использует форматы ISO 8601 , оканчивающиеся либо на +00:00 для смещения нулевых часов-минут-секунд от UTC, либо на его ярлык Z (произносится как «зулу»).

String output = Instant.toString() ;   // Generate string in standard ISO 8601 format.

2019-09-30T20: 04: 56.827546Z

Возможно, вы захотите урезать до миллисекунд, если ваш приемник данных не может обрабатывать микросекунды.

Instant instant = Instant.now().truncatedTo( ChronoUnit.MILLIS ) ;  // Lop off the microseconds, keeping milliseconds. 

Parse.

Instant instant = Instant.parse( "2019-09-30T20:04:56.827546Z" ) ;

Больше не могу помочь, так как не использую ни Android, ни Azure, и вы не описали достаточно подробностей.

Теперь при нажатииэто в облачном хранилище сообщений (Azure Event Hub),

Push what? По какому API вызову? Ваша ссылка ведет на страницу в C #, а не на Java. И эта страница выглядит как получатель, а не установщик (не уверен, я не читаю C #).