C# 如何获得两个时区之间的时差以及日光节约

我需要根据用户的配置文件动态获取两个时区之间的差异

假设我是用户A，今天我的配置文件位于MST时区，它是源时区，而我的目标时区位于PST时区，那么我需要得到MST和PST的小时数差。假设3小时是差，那么我需要得到这3小时的差

同时，另一个用户B可能在CST时区，即源时区，目标时区在HST时区，那么我需要得到CST和HST的小时差。假设1小时是差，那么我需要得到这一小时的差

如果“N”个用户正在使用该应用程序，并且如果他们使用夏令时，则应根据夏令时进行时区计算如果他们没有日光节约，则应在不考虑日光的情况下进行时区计算。

---

我如何实现这一点？谁能帮我一个忙，因为我是新手。

这个机制已经为我工作多年了。Windows使用一个注册表项来维护本地计算机的时区信息。但是，我不记得几年前的版本了。NET将读取时区信息包装到TimeZoneInfo对象中，在此之前，您必须自己编写包装。下面的psuedo显示了一般用法。基本租户包括：

1. Each client receives the time from the DB or other Layer as UTC. (all datetimes saved as UTC)
2. Using the client profile, convert the UTC DateTime value to the client's local value.
3. Display the date and do date math in the user's local time.
4. Before sending the time to the DB or another layer with different TZ convert back to UTC.

这会让你的约会逻辑保持健全

string userTimeZone = GetUsersTimeZone();
DateTime timeReadFromDBOrSomewhereInUTC = GetSomeDateTimeInUTC();


DateTime timeInUsersTimeZone = FromUTCToSpecificTimeZone(userTimeZone ,timeReadFromDBOrSomewhereInUTC );

edtTimeForAppointment.Text = timeInUsersTimeZone.ToString();

timeInUsersTimeZone.AddHours(2);

DateTime timeConvertedToUTCToSaveToDB = FromSpecificTimeZoneToUTC(userTimeZone,timeInUsersTimeZone);

下面是使用TimeZoneInfo的两个函数的示例

public static DateTime FromSpecificTimeZoneToUTC(TimeZoneInfo fromZone, DateTime specificTimeZoneDateTime)
{
    DateTime temp = DateTime.SpecifyKind(specificTimeZoneDateTime, DateTimeKind.Unspecified);
    return TimeZoneInfo.ConvertTimeToUtc(temp, fromZone);
}

public static DateTime FromUTCToSpecificTimeZone(TimeZoneInfo toZone, System.DateTime UTCTimeZoneDateTime)
{           
    return TimeZoneInfo.ConvertTimeFromUtc(UTCTimeZoneDateTime, toZone);
}

如果您只需要两个TIMRZONE之间的

DateTime

偏移量，那么下面的函数可能会很有用

public static TimeSpan GetTimeZoneOffsetDifference(TimeZoneInfo oldZone, TimeZoneInfo newZone)
{           
    var now = DateTimeOffset.UtcNow;
    TimeSpan oldOffset = oldZone.GetUtcOffset(now);
    TimeSpan newOffset = newZone.GetUtcOffset(now);
    TimeSpan difference = oldOffset - newOffset;
    return difference;
}

---

过去我们使用解析的

DateTimeOffset

来处理这个问题

• JavaScript在表单提交期间插入用户的本地时间

---

• 用户配置文件，其中以分钟为单位保存首选时区偏移

我们将偏移量存储为

SMALLINT

，而不是备选值，因为使用

TimeSpan.FromMinutes

非常容易，因此我们可以支持时区，而不仅仅是小时偏移量（如印度为UTC+5:30）

使用数据库中存储的日期时间偏移量和准确的UTC偏移量，我们可以按照自己的喜好进行报告（通过UTC或转换为首选时区），或显示符合我们要求的审计/数据表

---

话虽如此，我想还有更好的方法和许多其他方法。

偏移量的差异在时间上到底是什么？它会随着时间的推移而改变——因为PST和MST实际上不是时区，它们是“时区的一部分”。用户实际所在时区的IANA ID类似于America/Los_Angeles，在PST和PDT之间有所不同。你用粗体写的段落我也不清楚——这里N有什么用？如果目标时区不在DST中，但源时区在所讨论的瞬间，该怎么办？（例如，美国/洛杉矶目前正在观察DST，但欧洲/伦敦没有）。如果您完全控制您的应用程序，请评估utc强制所有请求和响应，并让客户使用utcdecide@BRAHIMKamel：这并不总是合适的。例如，如果用户希望将会议安排在“每周一上午9点”，则不能为此指定UTC值-这取决于用户的时区。UTC非常适合表示独立于时区的时间瞬间，但在许多情况下，用户的时区非常重要。@BRAHIMKamel：另一个例子，不适用于重复事件：在未来安排单个事件。您可能认为您知道基于用户时区的事件开始的UTC时间，但是如果这些时区规则发生更改怎么办？摩洛哥最近就是一个很好的例子——任何存储在最近规则更改之前计算的UTC值，但在规则更改之后计算的UTC值的软件现在都会有错误的本地时间。“有人能帮我吗？”是。如果您存储的是具有特定本地时间的用户意图的未来日期/时间值，则您的第1点从根本上被打破。时区规则可能会在将原始值转换为UTC的时间和将UTC转换回本地时间的时间之间发生变化，因此您可能不会得到用户要求的结果。我认为UTC只是用于简化时区数学的任意区域。由于UTC不随季节变化，且偏移量为0，因此我猜它被选为最适合用于标准化时间的区域。保存数据的用户的时区。例如，可能在明年或几年内改变，以在欧洲废除DST。如果你将（比如）2022年11月10日巴黎的当地时间上午9点转换为UTC，那么到2022年11月10日的时候，这一时间点很可能不会是巴黎的上午9点。如果用户指定上午9点，然后您的应用程序显示上午8点，我会将其归类为bug。相反，如果您保存实际提供的数据，那么您可以在任何时间点应用已知的时区规则。当两个时区之间的dst存在延迟时，不会发生同样的情况吗。如果我将一条记录保存在阿姆斯特丹当地时间，并在美国查看它，将有大约两周的时间延迟，时间与预期时间相差一小时，但是，这仍然遵循第四个时区转换规则。两周后，时间会赶上，不同之处在于补偿遵守延迟了两周。因此，对于您的代码来说，您可能很好——但值得注意的是，“标准化为UTC”的总体指导原则无论如何都不会适用于所有应用程序，尽管该指导原则在业界非常普遍：(“我们在其中以分钟保存首选时区偏移量的用户配置文件”-对于没有固定偏移量但遵守DST的时区，该配置文件如何工作？对时区规则的更改如何？很好-肯定存在差距。JavaSc