java时区混淆。大约2个小时的轮班时间，两个时间戳应该保持UTC时区

我使用以下代码：

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)

在Android应用程序中以UTC为单位生成事件时间戳

示例输出可以是：

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

现在，当将其推送到云消息存储（azure事件中心）时，会添加一个提交时间为UTC的字段（enqueuedtimeutc，）

但是，在计算距离时，两个时间戳之间有将近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个小时的间隔（因为智能手机通常会与时钟同步，所以这种情况也不太可能发生）。 为什么时差不是完全

2小时*60分钟*60秒=7200秒，而是更低？
由于需要增加延迟和处理时间，我希望这个值会更大

编辑
也许最好使用：

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

但这不应该改变任何东西，即完全（除了格式字符串）匹配我的时间输出

我以为两个时间戳都是UTC

不完全是

永远不要调用
LocalDateTime。现在我无法想象这样做有什么意义。当然不是在这种情况下

该类没有任何时区或UTC偏移的概念。所以它不能用来追踪一个时刻。
LocalDateTime
只保存一天中的日期和时间。因此，如果您使用
LocalDateTime
在
America/Montreal
中捕捉到2020年1月23日中午的当前时刻，您只需扔掉蒙特利尔信息。因此，我们只剩下一天中的日期和时间。我们再也不知道你指的是日本东京的中午，突尼斯突尼斯的中午，还是美国加利福尼亚州洛杉矶的中午——所有这些都是我们相隔数年的不同时刻，没有一个是你的初衷。我们失去了你的初衷

您确实通过传递
ZoneOffset.UTC
捕获了UTC中显示的日期和时间，但使用
LocalDateTime
不会增加任何值，只会分散注意力或可能是意外的值

Instant
要捕获UTC中的当前时刻，请使用
Instant

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

ISO 8601
表示此类值的标准方法是使用以下格式，以a
+00:00
结尾，表示与UTC的偏移量为零小时分秒，或以其快捷方式
Z
（发音为“Zulu”）结尾

2019-09-30T20:04:56.827546Z

如果数据接收器无法处理微秒，则可能需要截断为毫秒

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

解析

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

我无法进一步帮助您，因为我既不使用Android也不使用Azure，而且您没有描述足够的细节

现在，当将其推送到云消息存储（azure事件中心）时

推什么？通过什么API调用？您的链接指向C#中的页面，而不是Java。而且该页面似乎是一个getter而不是setter（不确定，我不读C）

我以为两个时间戳都是UTC

不完全是

永远不要调用
LocalDateTime。现在我无法想象这样做有什么意义。当然不是在这种情况下

该类没有任何时区或UTC偏移的概念。所以它不能用来追踪一个时刻。
LocalDateTime
只保存一天中的日期和时间。因此，如果您使用
LocalDateTime
在
America/Montreal
中捕捉到2020年1月23日中午的当前时刻，您只需扔掉蒙特利尔信息。因此，我们只剩下一天中的日期和时间。我们再也不知道你指的是日本东京的中午，突尼斯突尼斯的中午，还是美国加利福尼亚州洛杉矶的中午——所有这些都是我们相隔数年的不同时刻，没有一个是你的初衷。我们失去了你的初衷

您确实通过传递
ZoneOffset.UTC
捕获了UTC中显示的日期和时间，但使用
LocalDateTime
不会增加任何值，只会分散注意力或可能是意外的值

Instant
要捕获UTC中的当前时刻，请使用
Instant

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

ISO 8601
表示此类值的标准方法是使用以下格式，以a
+00:00
结尾，表示与UTC的偏移量为零小时分秒，或以其快捷方式
Z
（发音为“Zulu”）结尾

2019-09-30T20:04:56.827546Z

如果数据接收器无法处理微秒，则可能需要截断为毫秒

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

解析

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

我无法进一步帮助您，因为我既不使用Android也不使用Azure，而且您没有描述足够的细节

现在，当将其推送到云消息存储（azure事件中心）时

推什么？通过什么API调用？您的链接指向C#中的页面，而不是Java。而且该页面似乎是一个getter而不是setter（不确定，我不读C#）。
是的，最好使用
Instant
（
Instant.now（）.toString（）
应该给出与代码行相同的结果）。如果您希望时间位于UTC以外的其他时区，请使用
ZoneDateTime
（或至少
OffsetDateTime
）并将明确的时区传递给其
now
方法，例如
ZoneDateTime.now（ZoneId.of（“欧洲/维也纳”）
。是的，最好使用
Instant
（
Instant.now（）.toString（）
应给出与代码行相同的结果）。如果您希望时间位于UTC以外的其他时区，请使用
ZoneDateTime
（或至少
OffsetDateTime
）并将一个明确的时区传递给其
now
方法，例如
ZoneDateTime.now（ZoneId.of（“欧洲/维也纳”）
。我知道使用您的方法和即时消息会更好。尽管如此，我仍然无法解释Azure Eventhub的偏移量。为了推送数据，我使用了它的RESTful API。很抱歉链接了错误的描述。基本上执行了对
https://$namespace.servicebus.windows.net/$eventHub
的POST请求。@GeorgHeiler编辑您的问题以显示一些实际情况