Android + (Java Time或ThirteenTenABP) ZonedDateTime.of产生了意想不到的结果。


语境

  • 这是一个运行在API 29上的Android应用程序(最小值为23)。
  • 我使用的是 13TenABP

问题

我只是简单地调试一些代码,我做了以下的工作。

val zonedDateTime = ZonedDateTime.of(
                          LocalDateTime.of(1900, 1, 1, 15, 15, 0),
                          ZoneId.of("Europe/Amsterdam"))

这将打印(toString() 作为:

1900-01-01T15:15+00:19:32[Europe/Amsterdam]

预期

我本以为会看到 1900-01-01T15:15+02:00:00[Europe/Amsterdam] 或类似。

由于夏令时的原因,目前阿姆斯特丹的UTC偏移量为+2。然而,我看到的是19分32秒。

这意味着,如果我使用类似的方法将分区日期时间转换为UTC,我得到的结果是(与上面的错误一致):19分32秒。

val utcZoned = zonedDateTime.withZoneSameInstant(ZoneOffset.UTC)

我得到的是(与上面的错误一致):

1900-01-01T14:55:28Z

所以现在是14点55分28秒,或者相当于15点15分(下午3点15分)减去19分32秒。

我是不是错过了什么?

我在模拟器上运行这个。ZoneId.getSystemDefault() 也返回相同的ZoneId + Offset。我开始硬编码阿姆斯特丹,看看我是否能发现一个差异。

另一种方法是简单地做。

ZonedDateTime.of(LocalDateTime.of(1900,01,01,15,15,0), ZoneId.of("Europe/Amsterdam")).offset

结果是 ZoneOffset

并与上面的十九分钟一致。

偏移量是: +00:19:32

我到底做错了什么?

我有没有试过 java.time.*?

是的,我删除了ThirteenTenABP,并将所有的导入替换为 java.time.* 并在Android O (8.x)上运行这个,看看原生Java8时间类是否会产生类似的结果,答案是:是的。

偏移量来自于偏移规则。

Amsterdam ZoneOffset Rules

但为什么是这些数字呢?

解决方案:

看起来是正确的,阿姆斯特丹的时区为 以前 根据时间 Westerkerk.

具体偏移量为+0h 19m 32.13s的原因是该时区以阿姆斯特丹Westerkerk教堂的塔楼Westertoren(东经4°53′ 01.95″)的平均太阳时为中心。

https:/en.wikipedia.orgwikiUTC%2B00:20。

铭记 文档的 ZonedDateTime.of

然后将本地的日期时间解析为时间线上的一个瞬间。

因此,它将使用当时使用的时区,而不是荷兰当前使用的时区,给你返回一个时间。

给TA打赏
共{{data.count}}人
人已打赏
未分类

错误:无法在只读事务中执行UPDATE。

2022-9-9 4:13:23

未分类

根据列条件提取到一个列表

2022-9-9 4:24:18

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索