我陷入了这种逻辑。我正在制作一个消息安排项目，我有来自不同国家的客户。让我们考虑亚洲（不遵守夏令时）和美国/纽约（观察夏令时）。
现在，我正在编写以下查询，以便在距当前时间10分钟内获得时间表：
select message,subject,person_or_group,customer_id from common_schedule where reminder_type_1 in('beforedays','beforehours') and now() between cast(reminder_time1 as datetime) and addtime(cast(reminder_time1 as datetime),'00:10:00')
现在，如果我们有两个记录，一个用于纽约（在夏令时下），另一个用于新德里：印度没有夏令时，我会得到错误的纽约数据，因为1小时应该是减去它。
还假设表DY（夏令时）中有一个额外的列，它具有值＆＃39; y＆＃39;或者＆＃39; n＆＃39;。
答案 0 :(得分：1)
一些事情：
当您使用MYSQL的now()函数（docs here）时，该值将在当前时区返回。
可以为系统设置全局时区，也可以为数据库设置每个连接（docs here）。
您可以使用MYSQL的CONVERT_TZ函数（docs here）从一个时区转换为另一个时区，或者在本地时区和UTC之间转换。
DST的布尔标志永远不是一个好主意，因为世界各国都会在不同的时间点观察DST。此外，各国经常更改关于何时观察夏令时的规则。所有不同的规则都包含在时区数据中，当您使用America/New_York这样的时区时，您会引用这些规则。
对于将来的活动安排，您应该存储活动的当地时间及其所属的时区。
根据您正在使用的数据量，您可能会考虑一种策略，该策略预先计算从其计划的本地时间开始运行的UTC时间。然后，通过比较UTC＆＃34; now＆＃34;然后，您可以更轻松地找到要运行的下一个任务。反对预先计算的列。但是，您应该准备定期重新评估UTC等价物，或者至少与收到时区数据更新时一样频繁。