未来的预订维护业务时区以在其他时区显示数据

Question

我正在为一家企业设置一个网络应用程序，该应用程序接受未来的预订，也可以重复进行。目前，只有商家可以进行预订。

商业规则：

• 该应用程序必须根据帐户注册时提供的公司地址为用户保存时区。所有活动都将在营业地址举行。更新：根据评论，此规则将更改为：将向使用地理编码服务的用户推荐时区（在找到匹配项的情况下），但用户必须确认他们的时区。

• 当从另一个时区登录时，webapp 应用程序预订系统仍应向用户显示为设置为业务时区。（可能的情况是用户正在国外开会，但仍想查看他们的预订）。这应该意味着他们仍然可以像以前一样使用系统，例如。通过添加新预订。但是，我认为这意味着系统必须忽略用户的本地时区，并将业务时区应用于任何预订事件。

我有一个为同一时区内的用户工作的预订系统。但是，当他们更改时区时，未来的预订日历就会中断。

我的应用程序是带有 postgresql 的 nodeJS。我感到困惑的是关于日期时间我应该坚持什么，以及要执行哪些相关转换。

我认为始终保存客户端区域设置日期时间（即使不使用，因为要求可能会更改）以及 UTC 时间是明智的。但我想我还必须构建一个日期（在 javascript 中），它采用所选的日期时间并将业务时区应用于此（使用例如？moment.tz.setDefault("America/New_York")）。查看日程安排信息时，我不确定如何在客户端上收到此日期。如何确保它与业务时区一起显示？

Answer 1

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