0

我有一个应用程序，其中所有 DateTime 始终是服务器的时间。这意味着一个时区。这个想法是使应用程序在世界范围内兼容。第一步是将数据库中存储的所有日期时间转换为UTC，这没问题。第二步是为用户假设一个时区（基于业务逻辑），并将其用作显示和解析用户输入的默认值。此外，如果 DateTime.Now 之类的方法和其他在没有明确时区/区域信息的情况下构造日期时间的方法调用也假定该时区/区域，那将是很好的。

这个想法是从数据库中为用户假设一个时区。我有用户和他的时区，没问题。
问题是表示逻辑。代码中到处都是 DateTime.now 方法，要转换所有这些方法需要做很多工作。
为了避免这种情况，我需要一个全局时区设置，其中 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
4

1 回答 1

1

如果您正在（或多或少）企业应用程序中寻找时区处理的最佳实践，我可以分享经过验证的：

  1. 以 UTC 格式存储所有日期和时间相关信息。将其存储为本地时间（在服务器或其他任何地方）总是会带来风险，即某个地方的某个人有一天会忘记转换它们，结果会不太理想。当然，这意味着日期和时间应该通过 DateTime.UtcNow 或选择适当的 DateTimeKind 来实例化（这也指解析）。

  2. 显然，您需要在将 DateTime 显示给最终用户之前转换时区。而且您肯定意识到您需要从某个来源获取此信息（因此是问题）。某个地方可能是客户端（这对于胖客户端特别适用，而对于瘦客户端的 JavaScript 则不太好），但也可能是用户配置文件。如果您的应用程序有用户配置文件，我肯定会建议允许用户选择首选时区。其他与 g11n 相关的设置将是电子邮件的首选文化或首选语言。所有这些设置都应该被检测和预选（因此用户不必考虑或更重要的是点击太多）。

  3. 要将DateTime类转换为另一个时区的本地时间，您将使用TimeZoneInfo类。有几种方法可以做到这一点......

如果你要实现这个方法，你可能会遇到时区名称的问题——它们在服务器的文化中，所以你需要外部化（移动到资源文件）TimeZoneInfoDisplayName向你展示的内容并让翻译人员完成他们的工作。

我所说的检测时区也只是一个简短的词。
在胖客户端上，您只需读取本地时区即可：

TimeZoneInfo currentTimeZone = TimeZoneInfo.Local;

使用 JavaScript（瘦客户端）并不是那么容易。您唯一可以获得的是给定日期的时区偏移量（可能因日期和时间而异）：

var date = new Date();
var offset = date.getTimezoneOffset(); // GMT offset in minutes
于 2011-07-14T20:12:20.600 回答