我使用的是烧瓶sqlalchemy和postgreSQL,显示的日期时间有问题,在调查这个问题时,我发现了另一件奇怪的事情:
在隐名模式下创建DB条目(chrome选项卡)会给出不同的/错误的时间。编辑:这与隐名模式无关,这两种情况都发生在正常模式下。我还没弄清楚原因。
这是代码:
我更改了数据库的默认时区:
ALTER DATABASE postgres SET timezone TO 'Europe/Berlin';
模式:
class User(UserMixin, Base):
__tablename__ = 'users'
date_added = Column(DateTime(timezone=True), nullable=False)
用于向DB添加日期时间的方法:
date_added=datetime.today()
它在DB中的外观(此时我的本地时间是13:53:46):
创建条目而不是隐藏
timestamp with time zone
2019-02-01 13:53:46.73817+01
在匿名中创建条目
timestamp with time zone
2019-02-01 12:53:46.73817+01
这真让我担心。这是完全错误的。即使我要将datetime对象转换为localtime。这两个条目都是同时完成的,但是显示不同的结果,这怎么可能?
另外,当在HTML中查看这些日期时,postgreSQL不应用偏移量,因此第一个日期看起来是正确的,但第二个日期是错误的。
起初,我只是想找到一种方法,将所有的日期时间对象存储在欧洲/柏林,并在欧洲/柏林时间返回它们,所以我不需要将UTC转换到欧洲/柏林,但现在我认为出了可怕的问题。
我还在任何地方双重检查了我的代码,我没有使用其他方法来操作datetime对象。
编辑
每次用户登录时,我都会保存一个日期。目前,我尝试了这个不是匿名的。我的本地时间是14:13:33
,但它保存到DB:2019-02-01 13:13:33.804339+01
中。这怎么可能?我知道这不可能是随机的,但现在它看起来像它的节省时间
编辑
我用SHOW timezone;
双重检查了所有有问题的表,它们都正确地返回了Europe/Berlin
。
发布于 2019-02-09 14:29:46
datetime.today()
返回当前本地时间的没有时区信息的时间戳 (返回的值为纯时区)。问题的根源在于,在SQL Alchemy的postgres适配器和postgres本身之间,它必须在时区猜测。正如您可能想象的那样,如果没有显式提供时区,计算机系统倾向于假设UTC,但是工具集的精确逻辑可能很复杂,很难调试(我的逻辑取决于计算机上的本地时区设置、db中的系统级设置、会话级设置和工具制造者的首选项)。您可以通过以下两种方法之一避开这一整罐蠕虫:
datetime.today()
替换为datetime.now()
,并传入所需的时区,以便始终处理时区感知值),因此计算机不需要假定时区。注意,在postgres中,timestamp with time zone
类型仍然以UTC的形式存储,没有额外的信息,数据库只是使用会话级别的配置来决定在输出时显示它的时区。
https://stackoverflow.com/questions/54480171
复制相似问题