夏令时更改后的 DateTimeOffset 显示

发布于 2024-11-25 08:40:37 字数 1016 浏览 1 评论 0原文

我有一个关于 DateTimeOffset 和夏令时的问题。为了解释我的问题,让我们假设现在的日期和时间是:

11/6/2010  10:15:00 AM 

如果我运行此代码:

DateTimeOffset myTime = DateTimeOffset.Now;
Console.WriteLine("Local time: " + myTime.ToLocalTime().DateTime);

然后我得到这个结果:

当地时间:2010年11月6日 10:15:00 AM

这意味着事件发生在上午 10:15(我的时区是山地夏令时间(-6 偏移))。

因此,然后我将此 DateTimeOffset 保存到我的 SQL Server 2008 db(作为 DateTimeOffset)。第二天我想将其显示给用户。但现在夏令时已经到期了。

如果我使用保存的关闭值(前一天)运行上面的 WriteLine,将显示什么?

数据库中存储的偏移量是-6。但现在夏令时结束了,当前的偏移量是-7。因此,据我了解 文档,它将首先转换我的时间到 UTC 时间(因此需要上午 10:15 并增加 6 小时(下午 4:15)。然后它将减去当地时间的当前偏移量(下午 4:15 - 7 = 上午 9:15)。

因此,如果我的数学正确,现在当我显示事件时,它会显示它发生在上午 9:15,而不是上午 10:15,

这不好,我想存储时区信息,但我需要我的时区信息。在同一时区保持静态的时间(这意味着如果事件发生在犹他州上午 10:15,那么下次我查看它(在犹他州)时,我需要看到它是在上午 10:15。 ,不管夏令时是否发生了变化,

我都不认为我是第一个遇到此问题的人。(或者我的事实是否错误?)

I have a question about DateTimeOffset and daylight savings time. To explain my question lets assume that right now the date and time is:

11/6/2010  10:15:00 AM 

If I run this code:

DateTimeOffset myTime = DateTimeOffset.Now;
Console.WriteLine("Local time: " + myTime.ToLocalTime().DateTime);

Then I get this result:

Local time: 11/6/2010 10:15:00 AM

Meaning that the event happened at 10:15 in the morning (my time zone is Mountain Daylight Time (-6 offset)).

So, then I save this DateTimeOffset to my SQL Server 2008 db (as a DateTimeOffset). The next day I want to display it to the user. But now daylight savings has expired.

If I run the above WriteLine with the saved off value (from the previous day) what will display?

The offset stored in the database is -6. But now that daylight savings is over, the current offset is -7. So as I understand the documentation, it will first convert my time to UTC time (so it takes 10:15 AM and adds 6 hours (4:15 pm). It will then subtract the current offset of the local time (4:15 pm - 7 = 9:15 AM).

So if I my math is right, now when I display my event, it will show that it occurred at 9:15 AM rather than 10:15 AM.

This is not good. I want to store time zone information, but I need my times to stay static in the same time zone. (Meaning that if the event happened at 10:15 AM in Utah, then the next time I look at it (in Utah), I need to see that it was at 10:15 AM, regardless if the daylight savings time change has happened.

I can't think I am the first one to have this issue. What do others do to fix this? (Or do I have the facts wrong?)

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

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

发布评论

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

评论(1

空名 2024-12-02 08:40:37

不,它不会添加当前偏移量 - 它会添加该日期的偏移量,该偏移量仍然是-6。因此它仍应显示 10:15AM,因为它知道所涉及的日期,因此知道该日期生效的时区规则。

顺便说一句,您可能很想分别存储简单的 UTC 时间和时区标识符。如果您要存储时区,那么仅使用 DateTimeOffset 对于 UTC 日期/时间不会特别有用。 (另一方面,更清楚的是,它确实代表时间上的一个瞬间 - DateTime是一种非常混乱的类型,它不允许您轻松表达您正在尝试的内容代表。)

当然,我个人建议您查看Noda Time,在我看来,这是非常有偏见的是一个更清晰的日期/时间API 比内置 API...但还没有完全准备好用于生产使用。 (不过我们正在到达那里......)

No, it won't add the current offset - it'll add the offset at that date which is still -6. So it should still display 10:15AM, because it knows the date involved, and thus the time zone rules in force on that date.

You may well want to store a simple UTC time and the time zone identifier separately, by the way. If you're storing a time zone, then using DateTimeOffset won't be particularly helpful over just a UTC date/time. (On the other hand, it's clearer that it does represent an instant in time - DateTime is a horribly confused type which doesn't let you easily express what you're trying to represent.)

Of course I'd personally encourage you to look at Noda Time which in my very biased opinion is a rather clearer date/time API than the built-in one... but which isn't quite ready for production use. (We're getting there though...)

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