每个用户的默认时区，在业务逻辑中设置
我有一个应用程序，其中所有日期时间始终是服务器的时间。这意味着一个时区。这个想法是让应用程序在世界各地兼容。第一步是将数据库中所有存储的 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
I have an application where all the DateTime's are always the time of the server. That means one time zone. The idea is to make the application compatible all over the world. The first step is to convert all the stored DateTime's in the database to UTC, that's no problem. Second step is to assume a timezone for the user (based out business logic), and to use as a default for displaying and parsing user input. Furthermore it would be nice if methods like DateTime.Now and other method calls that construct datetimes without explicit time zone/region information would also assume this time zone/region.
The idea is to assume a time zone for a user from the database. I have the user and his time zone, thats's no problem.
The problem is the presentation logic. There are DateTime.now methods all over the code, to convert all these methods is a lot of work.
To avoid that I need a global time zone setting where the DateTime knows which time zone it is. Preferably on a generic place.
class business logic
InitializeCulture()
set time zone for user
end function
end class
class presentation logic
sample()
TimeOfTheCurrentUser = DateTime.now
end function
end class
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您正在（或多或少）企业应用程序中寻找时区处理的最佳实践，我可以分享经过验证的实践：
将所有日期和时间相关信息存储在 UTC 中。将其存储为本地时间（在服务器上或其他任何地方）总是会带来这样的风险：某人在某个地方有一天忘记转换它们，结果将不太理想。当然，这意味着日期和时间应通过 DateTime.UtcNow 或选择适当的 DateTimeKind 实例化（这也指解析）。
显然，在向最终用户显示日期时间之前，您需要转换时区。而且您肯定意识到您需要从某些来源获取此信息（因此是问题）。这个地方可能是客户端（对于胖客户端特别有效，但对于瘦客户端的 JavaScript 则不太好），但也可能是用户配置文件。如果您的应用程序有用户配置文件，我绝对建议允许用户选择首选时区。其他与 g11n 相关的设置将是电子邮件的首选文化或首选语言。所有这些设置都应该被检测和预先选择（因此用户不必思考或更重要的是单击太多）。
要将
DateTime类转换为另一个时区的本地时间，您可以使用TimeZoneInfo 类。有多种方法可以做到这一点...如果您要实现此方法，您可能会遇到时区名称的问题 - 它们属于服务器的文化，因此您需要将 TimeZoneInfo 的
外部化（移动到资源文件） DisplayName向您展示并让翻译人员完成他们的工作。另外简单说一下我所说的检测时区的意思。
在胖客户端上，您只需读取本地时区即可做到这一点：
使用 JavaScript（瘦客户端），这并不那么容易。您唯一可以获得的是给定日期的时区偏移量（可能会根据日期和时间而变化）：
If you are looking for best practice for time zone handling in (more or less) enterprise application, I can share the proven one:
Store all date and time related information in UTC. Storing it as local time (on server or wherever else) always brings a risk that somebody, somewhere, someday forget to convert them and the results would be less than ideal. Of course it means that dates and times should be instantiated via DateTime.UtcNow or with proper DateTimeKind selected (this refers to parsing as well).
Obviously you need to convert time zone before displaying DateTime to end user. And you surely realize that you need to obtain this information from some source (thus the question). That somewhere could be client-side (which would work especially well with thick client and not so well with thin client's JavaScript) but could be just as well the user profile. If your application has user profiles, I would definitely recommend to allow user to select preferred time zone. Other g11n-related settings would be preferred culture for e-mails or preferred language. All of these settings should be detected and preselected (so the user does not have to think or more importantly click too much).
To convert
DateTimeclasses to local time in another time zone, you would use TimeZoneInfo class. There are several ways to do that...If you would implement this method, you may hit the problem with time zone names - they are in server's culture, so you would need to externalize (move to resource file) what TimeZoneInfo's
DisplayNameshows you and let translators do their jobs.Also just a quick word what I meant by detect time zone.
On thick client you would do that by simply reading local time zone:
With JavaScript (thin client) it is not that easy. The only thing you can get is a time zone offset (which could vary depending on date & time) on given date: