Python datetime utcnow vs Luxon Datetime.fromMillis？

Question

我正在努力理解在 Python 的 DateTime 上使用 .utcnow 与 .now 的含义。

这就是我感到困惑的原因：我住在法国。现在，我们的 UTC 时区有 +1 小时（冬季（现在）的 CET 时区/夏季的 CEST (+2) 时区）。

如果我取以下值：

dt = datetime.datetime.utcnow()
dt.strftime('%c') # Thu Dec  9 16:17:38 2021
int(dt.timestamp()) # 1639063064

这是正确的，现在在法国，17:17。 因此，据我了解，时间戳1639063064 是自 EPOCH 以来时间的 UTC 表示。

但如果我在网站Epoch Converter 中测试这个值，我会得到

• GMT：2021 年 12 月 9 日星期四 15:17:44
• 您的时区：jeudi 2021 年 12 月 9 日 16:17:44 GMT+01:00

似乎该网站也将我的时区减去了一个已经“减去”的值，最终删除了两倍的时区并导致无效值。

真正的困惑是当我尝试在我的前端应用程序上将该 UTC 时间戳导入 Luxon 时，执行以下操作不起作用：

DateTime.fromMillis(parseInt(ts), { zone: 'utc' }).toLocal().setLocale('en')

我落后一小时。

我如何“告诉”Luxon 当前的 TS 处于 UTC 时区，并且调用 toLocal 将应用正确的用户时区？

Answer 1

似乎该网站也减去了我的时区 t

不，epochconverter.com 没有做任何事情。值 1639063064 确实确实代表 2021-12-09T15:17:44Z。这不是你想要的值。

我不是 Python 专家，但我认为问题在于 this utcnow() behavior 的组合（强调我的）：

返回当前 UTC 日期和时间，使用 tzinfo None。

这类似于now()，但返回当前的UTC日期和时间，作为一个简单的日期时间对象。

还有this timestamp() behavior：

假定原始日期时间实例表示本地时间，并且此方法依赖于平台 C mktime() 函数来执行转换。

听起来你想听从这个建议：

可以通过调用datetime.now(timezone.utc) 来获取当前的UTC 日期时间。

所以只需将您的第一行更改为：

dt = datetime.now(timezone.utc)

...应该没问题的。