1 回答
TA贡献1886条经验 获得超2个赞
您应该始终存储与事件相关的时区。由于您说“所有活动都将在公司地址举行”,因此公司的时区是相关的。
如果这些是面对面的实际事件,则用户当前的本地时区根本不相关。例如,我希望如果我在洛杉矶预约牙医,即使我是从纽约预约的,我也会指定洛杉矶的时间。
但是,如果事件是虚拟在线事件,那么您可能还想在 UX 中添加一些逻辑以显示目标时区的时间和等效的本地时间。例如,如果我下周要与一个在洛杉矶的人进行视频通话,而我今天恰好在纽约,那么你不知道通话时我是否还在纽约,或者是否到那时我已经去洛杉矶旅行了。您应该允许我选择我在哪个时区创建约会,并显示那里的时间和我的等效本地时间。
时区本身应存储为varchar(14)
. IANA 2017c 为区域或链接标识符的各个部分建立了 14 个字符的限制,删除了唯一超过它的链接名称,Canada/East-Saskatchewan
. (如果您有包含该内容的旧数据,请将其替换为America/Regina
。)
对于单个约会,您应该在约会的时区中存储约会的日期和时间。您应该将其存储在一种数据类型中,该数据类型包含没有任何时区或偏移量的日期和时间。 timestamp without time zone
在 postgres、datetime2
MS Sql Server 等中。
您可能认为您应该使用 a timestamp with timezone
(或datetimeoffset
在 SQL Server 中键入),但这会将约会固定到等效的通用时间,使用安排约会时适用的规则。如果这些规则在任命生效之前发生变化,那么任命将转移到不同的当地时间。这通常是不希望的。重点是捕捉用户的意图。换句话说,如果我说“12 月 1 日早上 8 点”,那么我的意思是不管我的政府从现在到我的约会时间对我的时区做了什么。
您也可以将等效的 UTC 时间存储在一个单独的字段中,但是您需要在服务器的时区数据更新时重新计算它。(这样的字段可以方便快速查询即将发生的事件。)
对于定期约会,以上所有内容仍然适用,只是您需要存储某种形式的重复规则。有些人喜欢为规则的各个组成部分存储许多字段(例如一个字段用于“每天”,一个字段用于“星期三”,一个字段用于一天中的时间,等等)。如果愿意,您可以在数据库中使用date
and类型。time
其他人喜欢存储带有 chron 表达式的字符串。这真的取决于你的需要。
考虑到每次出现的 UTC 等效值不一定相同,对于定期约会尤为重要。考虑到许多时区根据夏令时是否有效来交替其 UTC 偏移量。例如,如果我在洛杉矶创建一个每天上午 10 点的约会,那么太平洋标准时间为世界标准时间下午 6 点,太平洋夏令时间为世界标准时间下午 5 点。因此,您不能只存储 UTC 时间。同样,捕捉用户的意图是最重要的部分。
添加回答
举报