MySQL:DATE_SUB/DATE_ADD 占 DST?
这将返回
SELECT DATE_SUB(NOW(), INTERVAL 24*100 HOUR) = DATE_SUB(NOW(), INTERVAL 100 DAY);
100 天前的 1
(又名 TRUE
),一天中的时间没有改变。但由于美国实行夏令时,100 个二十四小时前的时间实际上比按天计算早一小时。如果上述语句考虑了 DST,它将返回 0
或 FALSE
。
有没有办法可以说明给定语句或会话的夏令时?我不想使用 UNIX_TIMESTAMP
因为它会切断 2038 年之后的任何内容。
This returns 1
(aka TRUE
)
SELECT DATE_SUB(NOW(), INTERVAL 24*100 HOUR) = DATE_SUB(NOW(), INTERVAL 100 DAY);
100 days ago, the hour of day does not change. But due to Daylight Savings Time (US), 100 twenty-four hour periods ago is actually one hour earlier than if you counted by days. If the above statement accounted for DST, it would return 0
or FALSE
.
Is there a way I can say to account for DST for a given statement or session? I would prefer not to use UNIX_TIMESTAMP
since it cuts off anything past 2038.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
这实际上只是转换为 UTC 并转换回来的问题:
这假设您已将时区表设置为使用命名时区。如果没有,您可以使用“+0:00”代替“UTC”
This is really just a matter of converting to UTC and back:
This assumes you have the timezone tables set up to use named time zones. If not, you can use '+0:00' instead of 'UTC'
当您可以确定 64 位整数时间戳将在至少 20 年前的所有地方实现时,切断 2038 年之后的任何内容怎么会成为一个真正的问题呢?
说真的,MySQL 中的日期时间/时间戳类型存在很多问题,您应该尽可能避免它们。
您是否存储了 2038 年之后的许多日期?
而且,为什么不尝试使用具有更高级类型支持的 PostgreSQL?
How would cutting off anything past 2038 be a real problem when you can be sure that 64bit integer timestamps will be immplemented everywhere 20 years before that at least ?
Seriously, there are so many issues with the datetime / timestamp types in MySQL that you should try and avoid them when possible.
Do you store many dates beyond 2038 ?
And, why not try using PostgreSQL which has much more advanced type support ?
您需要创建一个自定义函数,如下所示。
You'll need to create a custom function, something like this.