迭代一个月中夏令时更改的日子答案

【问题标题】：iterating through the days of a month when DayLight saving changes迭代一个月中夏令时更改的日子
【发布时间】：2013-10-13 14:31:22
【问题描述】：

我正在创建一个日期列表，该列表从该月的最后一天开始到下个月的第一天结束，全部采用 UTC。对于本月（2013 年 10 月），法国时区的用户在 9/30 @ 10PM 的月份开始 UTC 日期 CalendarMonthStartUTC 和他在 UTC 中的结束日期 CalendarMonthEndUTC 是 10/31 @ 11PM。

我有一个看起来像这样的循环：

DateTime StartTime = CalendarMonthStartUTC;
DateTime EndTime = new DateTime()

while (StartTime < CalendarMonthEndUTC)
{
     EndTime = StartTime.AddHours(24);
     ... do something here
     StartTime = StartTime.AddHours(24);
}

这个循环在除 10 月之外的所有月份都可以正常工作，因为夏令时更改会产生一个 OBO 错误，因为循环通过在每次迭代中添加 24 小时进行迭代。我想知道如何修改我的循环，使其不受夏令时的影响。

感谢您的建议。

【问题讨论】：

10 月的最后一个有效日期时间是 11 月 1 日之前的一个刻度。 UTC不受夏令时变化的影响，没有错误。
@HansPassant：当一天超过 24 小时（即在夏令时结束时增加一个小时）时不会出现错误，我只增加 24 小时。
不，UTC 天数始终为 24 小时。当您将 UTC 日期时间转换为本地时间时，由于 DST 更改，您最终可能会得到更多或更少的天数。
如果您想考虑特定的小时间隔（并为每个间隔执行中间计算，如您的代码中所示），您必须考虑夏令时（以及行中的代码我写的答案）；但就你对一整天的兴趣而言，Ergwun 的方法显然更好。我也确实专注于时间，在这里失去了真正的意义（我编写的代码工作正常，但不必要地复杂）。
嗯...除非每天的特定时间（开始时间和结束时间）对您很重要（不确定您在“//...在这里做某事”部分中在做什么），那是，如果尽管增加了天数，您仍想知道“小时级别”会发生什么。如果您需要对每次迭代中发生的事情进行更多控制（并且每次都考虑夏令时），请告诉我，我可以取消删除我的答案。正如您提出的问题，Ergwun 的回答似乎是最充分的解决方案。

标签： c# timezone

【解决方案1】：

你不能只在本地时间工作，最后转换为 UTC 吗？

如果你想对本地机器上当前设置的时区进行计算，那么你可以这样做：

        DateTime calendarMonth = new DateTime(2013, 10, 1, 0, 0, 0, DateTimeKind.Local);
        DateTime startDay = calendarMonth.AddDays(-1);
        DateTime endDay = calendarMonth.AddMonths(1);

        while (startDay <= endDay)
        {
            Console.WriteLine(startDay + " = " + startDay.ToUniversalTime());
            startDay = startDay.AddDays(1);
        }

如果您想计算给定时区的时区而不考虑本地机器设置，那么您可以像这样转换为 UTC：

        var timeZone = TimeZoneInfo.FindSystemTimeZoneById("W. Europe Standard Time");
        var utcTime = TimeZoneInfo.ConvertTimeToUtc(startDay, timeZone));

【讨论】：

但是如果 OP 需要执行中间计算（在 startDate 和 endDate 之间）并且不考虑夏令时，就会累积错误，不是吗？
@varocarbas 不确定您在说什么类型的计算？生成 UTC 时间列表后，您可以根据需要使用 UTC 时间进行间隔计算等。
我现在更正确地阅读了您的代码，但我错了：您通过忽略时间问题来增加天数！毫无疑问，这是一个更好的解决方案。我太专注于我误读了你的代码的时间，对不起。为您+1 :) 我删除了我的答案，因为只有考虑到特定时间才有意义；一整天，你的无疑更好。
在本地时间工作是正确的通用方法，但此特定代码仅在用户计算机上运行时才有效，例如在桌面或移动应用程序中。如果它以任何方式在 服务器 上运行，例如在 Web 应用程序中，则应避免使用 DateTimeKind.Local 和 .ToUniversalTime()，并改用 TimeZoneInfo 类上的方法。跨度>
@MattJohnson 好点。我以为这是本地机器上指定的时区。我添加了一个 sn-p 用于从指定的其他时区的本地时间进行转换。