我有一个应用程序，其中所有的DateTime始终是服务器的时间。这意味着一个时区。其想法是使应用程序在全世界都兼容。第一步是将数据库中存储的所有DateTime转换为UTC，这没有问题。第二步是为用户假设一个时区(基于业务逻辑)，并将其用作显示和解析用户输入的默认值。此外，如果DateTime。Now和其他没有明确时区/地区信息的构造日期时间的方法调用也将假定此时区/地区。
这个想法是为数据库中的用户假设一个时区。我有用户和他的时区，这没有问题。
问题在于表示逻辑。有DateTime。现在代码中到处都是方法，转换所有这些方法是很多工作。
为了避免这种情况，我需要一个全局时区设置，其中DateTime知道它是哪个时区。最好是在通用的地方。
class business logic
InitializeCulture()
set time zone for user
end function
end class
class presentation logic
sample()
TimeOfTheCurrentUser = DateTime.now
end function
end class
如果您正在寻找(或多或少)企业应用程序中时区处理的最佳实践，我可以分享一个经过验证的实践:
-
以UTC格式存储所有日期和时间相关信息。将其存储为本地时间(在服务器上或其他任何地方)总是会带来风险，即某个人在某个地方忘记转换它们，结果将不太理想。当然，这意味着日期和时间应该通过DateTime实例化。UtcNow或选择适当的DateTimeKind(这也指解析)。
-
显然，在向最终用户显示DateTime之前，您需要转换时区。您肯定意识到您需要从某些来源获得这些信息(因此出现了问题)。这个地方可以是客户端(这将特别适合厚客户端，而不适合瘦客户端的JavaScript)，但也可以是用户配置文件。如果您的应用程序有用户配置文件，我绝对建议允许用户选择首选时区。其他与g11n相关的设置包括电子邮件的首选文化或首选语言。所有这些设置都应该被检测和预选(所以用户不需要思考或更重要的是点击太多)。
-
要将
DateTime类转换为另一个时区的本地时间，您可以使用TimeZoneInfo类。有几种方法可以做到这一点…
如果你要实现这个方法，你可能会遇到时区名称的问题——它们在服务器的文化中，所以你需要外部化(移动到资源文件)TimeZoneInfo的DisplayName显示给你的内容，让翻译人员做他们的工作。
也只是简单地说一下我所说的检测时区是什么意思。
在厚客户机上，只需读取本地时区:
TimeZoneInfo currentTimeZone = TimeZoneInfo.Local;
使用JavaScript(瘦客户端)就不那么容易了。你唯一能得到的是一个时区偏移量(可能会因日期而异)。时间):
var date = new Date();
var offset = date.getTimezoneOffset(); // GMT offset in minutes