启用不同时区的工作
我有一个 asp.net + c# 应用程序，它使用 System.DateTime.now 来记录员工的工作时间。该应用程序已上线，最近我有来自国外的用户连接到该应用程序。
我有一位客户希望他在国外工作的员工根据他们的时区记录他们的工作时间。
数据库中记录的所有日期和时间都不是通用时间，因此我不想尝试将所有内容向后更改为 UTC（我也认为这不适用）。
我知道检测用户时区和地理位置的方法。问题是我不相信两者的准确性水平。总之，我认为我应该让管理员通过界面来定义时区，然后用户将选择他希望使用的时区。
这是正确的方法吗？对此的最佳实践是什么？ 10q 非常喜欢。
I have an asp.net + c# application that uses System.DateTime.now for logging working hours of employees. the application is online and recently I have users connecting to it from outside of my country.
I have a client that wants his employees working abroad to log their working hours according to their timezone.
All the dates and hours that are documented in the db are not in universal time so I don't want to try and change backwards everything to UTC (I also think that's not applicable).
I'm aware of ways to detect the user's timezone- js and geo-location. the thing is I don't trust the accuracy level of both. in conclusion I thought i'd let the admin define through an interface time-zones and the user will pick the one he wishes to use.
Is this a proper way? What is the best practice for this?
10q very much.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为让管理员为一组用户定义时区的方法很有意义。您经常会发现人们在台式电脑上定义了错误的时区，这又增加了一个复杂性。如果您明确设置它，那么您是安全的。
我强烈建议您在数据库中使用 UTC。如果您开始在同一数据库中混合来自不同时区的日期时间，这将会给您带来麻烦！
I think your approach of having an admin define the timezones for a group of users makes a lot of sense. You will quite often find that people have the wrong timezone defined on their desktop PCs, adding another complication. If you set it explicitly, you are safe.
I would urge you to use UTC in your database. If you start mixing DateTimes which are from different timezones in the same database this is going to come back to bite you!
在我的书中，将日期时间存储在 UTC 中绝对是最佳实践。转换现有数据可能需要大量工作，但从长远来看，如果您已经在不同时区拥有一些用户（今天是两个，但很快可能会是三个、四个），那么从长远来看，这可能是值得的....) 它还可以更轻松地避免夏令时转换等问题，特别是如果这些组所在的地区夏令时的开始和结束时间不同，例如美国和英国之间的情况（我必须处理这些 DateTime我的系统中的问题）。
当数据输入用户界面时，我不会依赖于对用户时区的任何自动检测。我要做的第一件事是将数据库中的用户与时区属性关联起来。听起来您的用户并没有太大改变他们的时区（如果有的话）。
如果您还没有这样做，那么将位置与用户或用户组关联起来应该不会太困难。只需添加时区信息及其位置，并在根据您的输入创建 DateTime 对象时在代码中使用该信息。这意味着需要有人管理多一份数据，但这比尝试通过代码自动检测时区要麻烦得多。
既然您要添加新时区，那么很容易会错过转化。我建议确保所有 DateTime 逻辑都是集中的（扩展方法或辅助类，具体取决于您的框架版本）。将所有转换和字符串格式保存在一个位置，并确保所有代码都引用它。
祝你好运，并围绕你的转换编写大量单元测试。
Having the DateTimes stored in UTC is definitely a best practice in my book. It may be quite a bit of work to convert your existing data, but it's probably going to be worth it in the long term if you already have a few users in different time zones (today it's two, but soon it could be three, four....) It's also going to make it easier to avoid problems around things like daylight savings time conversions, especially if the groups are in regions where the start and end of daylight savings is different, which is the case between the US and UK (I have to deal with these DateTime issues in my system).
I would not rely on any automatic detection of a user's timezone when data is entered into your UI. The first thing I'd do is associate users in the database with a timezone property. It doesn't sound like your users are changing their timezones much, if ever.
It shouldn't be too difficult to associate locations with either users or groups of users if you're not already doing it. Just add the timezone information along with their location, and use that in your code when creating a DateTime object from the input from your. It means one more piece of data that someone will have to manage, but it's going to be less troublesome than trying to automatically detect the timezone through code.
It's going to be very easy to miss conversions now that you're adding a new time zone. I would recommend making sure all your DateTime logic is centralized (extension methods or a helper class, depending on your framework version). Keep all your conversions and string formatting in a single place and make sure all your code references it.
Good luck, and write lots of unit tests around your conversions.