仅对日期和时间进行时区转换 - 有必要吗?

发布于 2024-10-01 10:10:45 字数 1029 浏览 8 评论 0原文

我们一直致力于为我们的 Web 应用程序实现时区支持。

这篇很棒的帖子为我们提供了很多帮助:夏令时和时区最佳实践

我们已经在 MYSQL 中实现了 OLSON TZ 数据库,并使用它进行 TZ 转换。

我们正在构建一个调度应用程序,以便:

我们将在 UTC 时间的特定日期和特定时间发生的所有预订存储在 DateTime 字段中,并使用 CONVERT_TZ() 进行转换。这很好用。

我们不太确定的是假期和休息之类的东西:

假期只是日期参考,不包括时间部分。因为 CONVERT_TZ() 不适用于日期对象,我们猜测我们最好只根据用户的时区存储日期值?

id1 id3 startDate   endDate
-----------------------------
3   6   2010-12-25  2011-01-03
4   3   2010-09-22  2010-09-26

一周中每一天存储期间的重复休息也是如此。目前,我们将一周中每一天的休息时间索引为 0-6。因为这些只是时间对象,所以我们不能使用 CONVERT_TZ() 并假设我们应该将它们存储为用户时区的时间值?

bID sID dayID startTime  endTime
--------------------------------
1   4   1   12:00:00    14:00:00
2   4   4   13:30:00    13:30:00

在这种情况下,对于假期和休息时间,我们只会在预订时间转换为用户当地时间后将它们与预订时间进行比较。

这是处理事情的正确方法吗?还是我们应该以其他方式存储假期和休息时间,以便我们可以将它们转换为 UTC(不确定这对于休息时间有何作用)。

感谢您的帮助!

We've been working on implementing timezone support for our Web app.

This great SO post has helped us a bunch: Daylight saving time and time zone best practices

We've implelmented the OLSON TZ database in MYSQL and are using that for TZ conversions.

We're building a scheduling app so:

We are storing all our bookings which occur on a specific date at a specific time in UTC time in DateTime fields and converting them using CONVERT_TZ(). This is working great.

What we aren't so sure about is stuff like vacations and breaks:

Vacations are just Date references and don't include a time portion. Because CONVERT_TZ() doesn't work on date objects we are guessing that we are best to just store the date value as per the user's timezone?

id1 id3 startDate   endDate
-----------------------------
3   6   2010-12-25  2011-01-03
4   3   2010-09-22  2010-09-26

Same thing with recurring breaks during stored for each day of the week. We currently store their breaks indexed 0-6 for each day of the week. Because these are just time objects we can't use CONVERT_TZ() and assume we should just store them as time values in the user's time zone?

bID sID dayID startTime  endTime
--------------------------------
1   4   1   12:00:00    14:00:00
2   4   4   13:30:00    13:30:00

In this case with vacations and breaks we would only compare them to booking times AFTER the booking times have been converted to the user's local time.

Is this the correct way to handle things, or should we be storing both vacations and breaks in some other way so that we can convert them to UTC (not sure how this would work for breaks).

Thanks for your assistance!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

撕心裂肺的伤痛 2024-10-08 10:10:45

这两种存储格式看起来都不错。当您将它们从表中取出时,您只需将它们转换为用户的当地时间即可。

实际上,对于休息表,我认为它们名义上已经是当地时间,因此您只需直接与约会的当地时间进行比较即可。

The two storage formats look fine. You just need to convert them to the user's local time when you pull them out of the table.

Actually, for the breaks table I presume they're already nominally in local time, so you just compare directly against the local time of the appointment.

晒暮凉 2024-10-08 10:10:45

我不太理解你的问题,无法说我的答案对你来说是100%正确的。但我认为您需要做的是将 DateTime 存储在“本地”时间并存储时区。这样,即使夏令时发生变化(这种情况发生),您也能保持正确。

好文章,位于 http:// blogs.windwardreports.com/davidt/2009/11/what-every-developer-should-know-about-time.html(是的)。

I don't understand your question well enough to say my answer is 100% correct for you. But I think what you need to do is store the DateTime in "local" time and also store the timezone. This way you have it correct even if daylight savings time shifts (which happens).

Good article at http://blogs.windwardreports.com/davidt/2009/11/what-every-developer-should-know-about-time.html (yes by me).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文