管理时区和JavaScript 应用程序的 DST 问题 [英] Managing timezone & DST issue for javascript application

问题描述

我正在尝试创建一个日程安排应用程序.前端\UI 是使用JavaScript 开发的.后端是一个 ASP.NET Web Api 应用程序，它使用 MSSQL 服务器作为数据库.从用户界面，用户将安排一个可以每天/每周/每月运行的作业.每个作业最多可以运行 3 个月.作业将在指定时间在服务器端运行.

假设用户来选择一个将在当地时间上午 10 点运行一周(从 11 月 23 日到 11 月 29 日)的作业.在这种情况下，我将从 11 月 23 日开始在数据库中创建七个条目(每天一个).每行都有开始时间、开始日期和一些与状态相关的列.

我有以下问题:

1. 如何在 SQL Server 上存储时间信息(本例中为上午 10 点)?
2. 我是否应该在客户端机器上使用 JavaScript 获取时间，然后将其转换为 UTC?
3. 我是否应该使用 JavaScript 获取时间并保存用户时区信息?
4. 当 DST 相关更改生效时会发生什么?
5. 像 momemnt.js 这样的库在这种情况下会有所帮助吗?

我正在考虑保存用户时区信息并将他的本地时间保存在服务器上.

解决方案

警告 - 正确安排时间很困难.还有很多需要考虑.请阅读这个和这个.您的大部分问题都在那里得到解决(尽管从其他语言的角度来看，挑战是相同的).

您还可以查看 Quartz.net，这对于很多场景来说已经足够了.

回答您的具体问题:

<块引用>

1. 如何在 SQL Server 上存储时间信息(本例中为上午 10 点)?

对于重复规则，存储事件的本地时间.SQL Server 有一个 time 类型，它适用于存储一天中的时间.您将需要其他字段来跟踪时区、开始日期、星期几和其他模式信息.

对于计划运行的特定实例，您根据重复规则中的所有信息计算 UTC datetime.至少，您安排下一次 发生，并在每次运行后重新计算.在某些情况下，您可能决定投影接下来的 N 次出现，具体取决于您需要向用户显示的内容.(您也可以为此使用 datetimeoffset.请参阅 datetime vs datetimeoffset.)><块引用>

2. 我是否应该在客户端机器上使用 JavaScript 获取时间，然后将其转换为 UTC?
3. 我是否应该使用 JavaScript 获取时间并保存用户时区信息?

要回答这两个问题:对于安排，您不应丢弃原始输入，该输入将位于正在安排的事件的本地时区.这可能与用户的时区匹配，也可能不匹配.您需要要求用户选择活动的时区.

<块引用>

4. 当 DST 相关更改生效时会发生什么?

这取决于你.您需要对此进行彻底测试.一般来说，有一段本地时间被跳过，一段本地时间被重复.

• 当它被跳过时，您必须决定何时运行该事件.选项包括:1) 在跳过时间之前，2) 在跳过时间之后，以及 3) 根本没有.在大多数情况下，首选选项是在跳过的时间之后运行，通过将本地时间提前 DST 偏差(通常为 1 小时).例如，计划在太平洋时间每天 2:30 运行的每日活动将在春季向前过渡当天的 3:30 运行.

• 当它重复时，您必须决定何时运行该事件.选项包括:1) 在第一次出现时，2) 在第二次出现时，以及 3) 在两次出现时.在大多数情况下，首选选项是仅在 第一次 出现时运行.例如，计划在太平洋时间每天 1:30 运行的每日活动将在太平洋时间 1:30 而不是太平洋标准时间 1:30 运行.

  • 例外情况包括处理营业至深夜并选择重复营业的企业.例如，酒吧、餐厅或电影院.它高度依赖于特定用例和特定业务所做的选择.

<块引用>

5. 像 moment.js 这样的库在这种情况下会有所帮助吗?

不是从日程安排的角度来看，不是.不过，它可以帮助解析、格式化和验证输入.您还可以使用 moment-timezone 来帮助选择事件的时区.如果你在后端使用 node.js 运行它，那么也许会有更多好处.

<小时>

最大的挑战其实是你没有提到的一个，那就是在你的服务器上维护时区数据.在您的 C# 代码中，我建议为此使用 Noda Time，而不是 TimeZoneInfo.然后，您可以根据需要自己更新 tzdb 数据.您还需要考虑重新安排每次出现的 UTC 时刻的工作流程，以防时区已更改其偏移或夏令时日期.

I am trying to create a scheduling application. The front end\UI is developed using JavaScript. The back end is a ASP.NET Web Api application which uses MSSQL server as the database. From the UI, user will schedule a job which can run daily/weekly/monthly. Each job can run for maximum of 3 months. The job will run on the server side at the specified time.

Assume user come and selects a job which will run for a week (From 23-Nov to 29-Nov) at 10 AM local time. In this case, I will make seven entries in the database starting from 23 nov (One for each day). Each row will have Start time, Start Date and some status related columns.

I have following querstions:

1. How do I store time information (10 AM in this case)on SQL server?
2. Should I get the time using JavaScript on client machine and then convert the same to UTC?
3. Should I get the time using JavaScript and also save the user time zone information?
4. What happens when DST related changes take effect?
5. Will library like momemnt.js will help in this scenario?

I am thinking of saving user timezone information and the saving his local time on the server.

解决方案

Warning - Scheduling properly is hard. There's a lot more to consider. Please read this and this. Most of your questions are addressed there (though from the perspective of other languages, the challenges are the same).

You might also take a look at Quartz.net, which is sufficient for many scenarios.

To answer your specific questions:

1. How do I store time information (10 AM in this case) on SQL server?

For the recurrence rule, store the local time of the event. SQL Server has a time type, which works well for storing the time of day. You will need other fields for tracking the time zone, the start date, days of the week, and other pattern information.

For the specific instance that is scheduled to run, you calculate the UTC datetime based on all the information in the recurrence rule. At minimum, you schedule the next occurrence, and recalculate after each run. In some cases, you may decide to project the next N occurrences, depending on what you need to show to the users. (You could also use a datetimeoffset for this purpose. See datetime vs datetimeoffset.)

2. Should I get the time using JavaScript on client machine and then convert the same to UTC?
3. Should I get the time using JavaScript and also save the user time zone information?

To answer both questions: For scheduling, you should not discard the original input, which will be in the local time zone of the event being scheduled. That may or may not match the time zone of the user. You will need to ask the user to select the time zone of the event.

4. What happens when DST related changes take effect?

That's up to you. You will need to test this thoroughly. In general, there is a period of local time that is skipped, and a period of local time that is repeated.

• When it is skipped, you have to decide when to run the event. Options include: 1) before the skipped time, 2) after the skipped time, and 3) not at all. In most cases, the preferred option is to run after the skipped time, by advancing the local time by the DST bias (usually 1 hour). For example, a daily event scheduled to run at 2:30 every day in Pacific time would run at 3:30 on the day of the spring-forward transition.

• When it is repeated, you have to decide when to run the event. Options include: 1) at the first occurrence, 2) at the second occurrence, and 3) at both occurrences. In most cases, the preferred option is to run at the first occurrence only. For example, a daily event scheduled to run at 1:30 every day in Pacific time would run at 1:30 PDT, and not at 1:30 PST.

  • Exceptions to this include dealing with businesses that are open late into the evening and choose to stay open for the repeated hour. For example, a bar, restaurant, or movie theater. It is highly dependent on the specific use case and the choices made by the specific business.

5. Will library like moment.js will help in this scenario?

Not from a scheduling perspective, no. It can help with parsing, formatting, and validating input though. You might also use moment-timezone to help with selecting the event's time zone. If you were running this with node.js on the back end, then perhaps there would be more benefit.

---

The biggest challenge is actually one you have not talked about, which is maintaining the time zone data on your server. In your C# code, I recommend using Noda Time for this, instead of TimeZoneInfo. You can then update the tzdb data yourself as needed. You also need to think about the workflow of rescheduling the UTC instants of each occurrence, in the case that a time zone has changed its offset or daylight saving time dates.

这篇关于管理时区和JavaScript 应用程序的 DST 问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！