（这是一个关于 UI 的问题，而不是实现它所需的技术）
向用户显示在不同时区发生的事件的时间最清晰的方法是什么？您的“普通”用户了解 UTC 和时区吗？
我们捕获本地时间和 UTC 偏移量并将其存储在数据库中 (SQL 2008 DateTimeOffset) 以用于在不同时区发生的事件。用户也位于不同的时区。
我将在下面提出几个答案，以便对其进行评分，但我会很感激其他建议。
编辑：我想避免在用户的时区显示时间。不同时区的用户会讨论相同的事件，如果他们位于不同时区的本地，就会产生混淆。
编辑：我想让这个问题变得通用，希望对更多人有用，但对于某些特定情况，这是一个用于跟踪包裹的 Web 应用程序（想想 FedEx）。包裹将跨越时区。客户支持在英国，但收件人可能在其他地方。
【问题讨论】：
像这样显示当地时间和偏移量 15:18 GMT+1
【讨论】：
始终以 UTC 显示时间
请注意，我不同意这一点。我只是将其添加为投票选项。
【讨论】：
用时区缩写显示它
代替
15:18 GMT+1
显示为中欧时间
15:18 CET
人们更习惯于查看自己的时区
【讨论】：
策略应该是用户界面中的时间——当向用户显示或输入时——在用户自己的时区。
另一方面，在应用程序中，即在 Ruby 代码和数据库中，时间始终保持在 UTC 时区中。
然后您的工作就是允许用户选择一个时区，然后根据需要在该时区和 UTC 时区之间来回转换。
这个article illustrates 如何在 Rails 环境中这样做。
这意味着能够检索用户时区或将该时区存储在“用户”表中。
【讨论】：
我认为如果没有特定的应用程序，这个问题就无法明确回答。例如，在同一时区的所有用户的 Intranet 应用程序中，您通常可以完全省略时区。对于股票市场应用程序，您可能希望将时间与市场的时区相关。对于社交网络应用程序，您可能希望将时间设置为相对于用户的时区。我认为适用的一般原则是：
【讨论】：
正如其他人所提到的，我认为如果应用程序是特定的或本地的，那么您可以省略时区，或者做出其他假设。
如果它是全局的，那么您希望一致地存储数据（始终为 UTC），然后转换为显示。此外，您可能希望让用户指定他/她的时区，并且可能还指定日期和时间格式；要么提供几个静态选项，要么赋予它们指定格式字符串的全部权力，如果它们足够先进的话。
如果您不想为用户提供选项，那么简单的 HH:MM TZ 或 HH:MM GMT+/-H 似乎就足够了？或者您甚至可以只显示服务器的本地时间，然后在脚注或常见问题解答中说“所有时间都是 PST”或其他任何时间。
作为用户，我更喜欢最大的可配置性，但我想我是有偏见的，作为一名程序员。
【讨论】：
我喜欢 GMT+offset（假设 offset“通常”是用户的时区）。作为附加线索，请提供一个工具提示，列出该时区中的一些城市（每个半球一个），或提供指向更详细说明时区的某个页面的超链接。
【讨论】：
尝试使用老式新闻编辑室图形，将时钟标记为“纽约”、“伦敦”、“东京”，然后是“巴布亚新几内亚”或特定观众所在的任何位置。您可以将时钟设为模拟时钟或数字时钟，或两者兼而有之。
没有人会对此感到困惑，而我认为大多数人并不真正了解 GMT+7（或其他）的含义。
【讨论】：
这是一个非常上下文敏感的情况。我想以 postos 和 tvanfosson 的建议为基础。我认为不需要城市和国家的名称，除了帮助人们设置他们的当地时间，也许在对话框中设置时间，当他们只知道所需的当地时间时（不压倒/分散注意力的巨大挑战）对他们来说很混乱的用户）。
如果一个地点与时间相关联，那么该地点的日期和时间通常是合适的（例如，当谈到市场收盘、事件、旅行到达和离开等时）。我赞成工具提示可用于将其转换为 (1) gmt 和 (2) 正在查看界面的用户的明显本地时间的想法。偏移量也很有用，还有涉及午夜穿越的日期。
我也同意时区应该明确表明它可能不是当地时间。此外，即使在没有时区的情况下显示本地时间，我认为工具提示仍然很重要。 （特别是当携带笔记本电脑旅行的人可能会保留他们的家乡时区设置。）
对细节的额外关注：处理夏令时、夏令时等的时间变化，以及它们在位置之间的差异（不是每个地方都有夏令时，不是每个地方都同时进行更改）以及不同地点之间的差异时间（尤其是未来）。
【讨论】：
最好的办法是将所有日期/时间信息存储在 UTC 中，然后显示与用户时间偏移的时间。 .NET 对此有各种支持——大多数其他环境也支持这一点。早上 7 点在伦敦输入数据的人应显示为美国东部时间凌晨 1 点或凌晨 2 点。关于 UTC 最好的部分是，当您在没有夏令时的地方时，它可以避免所有带有夏令时或缺乏夏令时的麻烦事情，例如。韩国、印度与北美的新偏移量。
我喜欢 24 小时制，例如美国东部夏令时间 15:30，但我相信有些人可以在 12 小时模式下工作。确保将其作为一个选项。
【讨论】：
多年来，“小型”应用程序突然在全国范围内（在美国，5 或 6 个时区）或全球范围内被“小”应用程序咬了好几次，如果可能，我总是将日期时间数据存储为 UTC。
问题就变成了显示问题，正如许多其他帖子所指出的那样。
如果显示日期/时间，并且它与当前用户的位置（和语言环境）相关，则以用户的本地时间显示。
如果要显示多个日期/时间并且它们与不同的位置（可能是不同的语言环境）相关，我发现 用户更喜欢以 12 小时格式查看以该位置的时区显示的时间。
考虑如何打印机票（至少在美国是这样） - 出发和到达时间显示在出发城市和到达城市的时区中。最佳路线还会显示“总行程时间”或持续时间。
好的，所以您想为用户显示区域设置格式的数据：您如何确定区域设置？对于 Web 应用程序，虽然大多数 HTTP 标头中都存在语言环境，但您不能总是相信用户机器上的语言环境设置正确。因此，我们几乎总是会要求用户设置一个配置文件，其中包含一些我们可以从中确定区域设置（邮政编码、城市/州/国家等）的数据，或者输入一些可以让我们了解位置的信息用户实际驻留（对于 Web 应用程序或“本机”应用程序）
自从通过 ip 地址进行地理定位变得广泛可用以来，我不必执行此操作，但这也不一定准确。
请注意，当我处理这些应用程序时，我的个人设置几乎总是以 24 小时格式、UTC、ISO8601 结束，这样我知道显示给我的时间是什么，而不管用户在哪里。
【讨论】：
您所描述的是页面查看者正在支持客户的情况。
所以我建议在设计时关注客户的角度。因此，默认或主要显示方法应该是客户的当地时间。如果您使用电子邮件或 IM，您应该有某种用户目录作为来源。如果你在打电话，那么来电显示可以作为时间转换的依据。
这也是一个示例，说明该软件只是其中的一部分，而不是整个支持服务。显示屏应允许轻松切换到其他时区，并且电话代表应始终接受培训，以便在提供任何基于时间的信息之前询问他们所在的时区。
它还应该有一个选项来显示到达点的当地时间。这使您能够以无缝且高效的方式与客户交谈：
CU: "When will it arrive?"
CS: "Based on your phone number, I am assuming you are in EST. The ETA is 8pm".
CU: "I am traveling in Chicago right now. Can you tell me when I should check back?"
(Phone rep taps a "CST" button on the screen, and the displays convert.)
CS: "Sir, if the package does not arrive before 9:10pm, your local time, please call us."
【讨论】：
你提到了包裹。物流中的惯例是始终显示当地时间，这就是 UPS 等在其跟踪数据中的状态历史记录中显示的内容。
如果本地时间不是当前用户的时区，那么我会考虑用时区注释时间，例如09:00（欧洲/阿姆斯特丹）。
请注意，地名比缩写更好，后者可能会模棱两可。您可以决定告诉用户时间在哪里，或者告诉用户与他们的时区的差异是否更有用。
避免该问题的一种方法是仅使用相对时间，例如4 小时前。
【讨论】：