我正在开发一种国际软件，它可以作为一个简单的项目管理软件，我遇到了一个问题。此问题与日期/小时和时区有关 当消息从一个时区发送到另一个时区时，我可以将UTC（GMT）时间存储在我的数据库中，然后根据用户的时区显示不同的时间。但是当我只与日期合作时，这是不可能做到的 如果我说任务是在3月21日。我是否应该考虑在其他一些国家这个日期可能是20或22？你对这个问题有什么建议？
答案 0 :(得分：5)
假设纽约的用户将项目的截止日期设置为“1月26日星期一的任何时间”。这意味着“在1月26日星期一0600至1月27日星期二0600”的任何时间“在布鲁塞尔和”从2000年1月25日星期日到2000年1月26日星期一的任何时间“在L.A.
所以在星期一26点完成任务在布鲁塞尔和纽约州完成，但在洛杉矶已经太晚了
一种可能的解决方法是永远不会只使用日期。如果未指定时间，则在用户时区指定的日期将其设置为0000小时或2400小时。
用户可能不得不处理奇怪的截止日期/时间，但作为一个曾经在国际上工作过的人来说，它与领土有关。
答案 1 :(得分：2)
如果不存储确切的时间，您将无法实现您的目标。你根本没有足够的信息。
答案 2 :(得分：2)
如果您没有时间，请假设时间是应用程序主区域设置中的业务结束，然后将该时间转换为其他任何时间。另一种方法是假设在当地时间结束工作日并将其调整为UTC。使用该应用程序的每个人都需要了解在未指定时间时所做的任何默认时间假设。在大型企业中协调主办公室可能是最好的，而在当地背景同等重要的高度分散的环境中协调当地时间可能是最好的。
答案 3 :(得分：2)
如果您没有存储分钟和秒数，则必须假设输入的日期是所需的日期，而不是GMT的任何调整。只需将其放在数据库中即可。无论您身在何处，西海岸的人们都必须假设到期日是一样的。如果要调整时区，则必须收集更多信息，例如小时，分钟和秒。
答案 4 :(得分：1)
最简单的解决方案就是为每个人显示相同的日期。截止日期实际上将是最新时区的午夜。
否则，确定截止日期的默认时间应该是创建任务的时区中的内容，例如美国东部时间3月21日美国东部时间17:00或美国东部时间3月22日00:00，并在当地时区显示。然后，时区差异将相应地推送到前一天或第二天。
答案 5 :(得分：1)
SQL 2008允许Date数据类型没有与之关联的任何时间值。这允许有人说我需要在此日期之前完成此操作，但我不在乎它是否是+/-几个小时。如果选择的日期是2009年1月1日，但它发生在2009年1月2日凌晨2点，他们可能不在乎。
当用户需要按特定日期和时间完成某些操作时，例如2009年1月1日关闭业务，那么您需要将其存储在DateTime中作为UTC并将其转换为本地时间客户端。
这将带来很大的复杂性，表明什么时候完成，它将在特定日期或特定时间附近完成。
答案 6 :(得分：0)
如果您有一个数据库实例，我会将所有日期存储在您的数据库服务器的日期时间戳中。如果要为行添加时间戳，请考虑使用T-SQL中的GetDate（）或作为带时间戳的日期列的默认值。然后，您始终拥有单个参考点。考虑那里的UTC格式。
然后，访问该日期的所有客户端都会将自己的转换转换为“本地时间”，这可以通过以下内容进行解释：用户首选项，客户端计算机上的日期时间戳等。
如果不了解更多信息，很难准确说出分辨率是什么。
答案 7 :(得分：0)
您的解决方案取决于您的应用和要求。
我首先在您的数据结构中存储UTC +偏移量，因此可以轻松显示任何时区。
如果任务或会议于伦敦时间21月3日中午12点到期，则最有可能发生在21月3日21:30在阿德莱德（+0930），但这是一个应用要求，而不是任何险恶的时区相关标准。
如果你想要最大的灵活性，添加一个标志，可以在任何时区同时或在同一时间，无论你在哪里（交错），并相应地显示事件。
答案 8 :(得分：0)
您可能希望将日期存储在可识别时区的日期中。这将有助于您进行计算。例如，SQL Server 2008支持datetimeoffset that does precisely this。或者，如果您正在使用SQL 2005并付出一些努力，则可以编写自己的SQL CLR数据类型来支持此功能。