Displaying time and timezone information to the user (what, not how)
(这是关于UI而不是执行此操作所需技术的问题)
将不同时区发生的事件的时间显示给用户的最明确方法是什么？您的"普通"用户是否了解UTC和时区？
我们捕获本地时间和UTC偏移量，并将其存储在数据库(SQL 2008 DateTimeOffset)中，以用于在不同时区发生的事件。用户也在各种时区。
我将在下面提出几个答案，以便对它们进行评级，但我会感谢其他建议。
编辑：我想避免在用户的时区显示时间。不同时区的用户将讨论相同的事件，如果他们是不同时区的本地事件，则会产生混淆。
编辑：我想让问题通用，希望对更多人有用，但对于某些特定的上下文，这是一个用于跟踪包裹的Web应用程序(想想FedEx)。包裹将跨越时区。客户支持在英国，但收件人可能在其他地方。
试试旧式的新闻编辑室图片，在这里您可以看到标有"纽约"，"伦敦"，"东京"和"巴布亚，新几内亚"的钟表，或者您的特定观众所在的位置。您可以使时钟模拟或数字或两者兼而有之。
没有人会对此感到困惑，而我认为大多数人都不知道GMT + 7(或其他)的含义。
显示当地时间和偏移，如格林威治标准时间15:18 + 1
你提到包裹。物流中的惯例是始终显示本地时间，这是UPS等在其跟踪和跟踪数据中在状态历史中显示的内容。
如果该本地时间不是当前用户的时区，那么我会考虑用时区注释时间，例如09:00(欧洲/阿姆斯特丹)。
请注意，地名比缩写更好，缩写可能不明确。您可以决定告诉用户时间在哪里，或与他们的时区有什么不同，这是更有用的。
避免该问题的一种方法是仅使用相对时间，例如4小时前
策略应该是UI中的时间 - 当用户显示或输入时 - 在用户自己的时区中。
另一方面，在应用程序中，即在Ruby代码和数据库中，时间始终保持在UTC时区中。
然后，您的工作变为允许用户选择时区，然后根据需要在此时区和UTC时区之间来回转换。
本文说明了如何在Rails环境中执行此操作。
这意味着能够检索用户时区或将该时区存储在"用户"表中。
您所描述的是页面查看器支持客户的情况。
所以我建议设计注重客户的角度。因此，默认或主要显示方法应该是客户的本地时间。如果您使用的是电子邮件或IM，则应将某种用户目录作为源。如果您正在通话，则来电显示可以作为时间转换的基础。
这也是软件如何只是其中一部分的一个例子，而不是整个支持产品的一部分。显示屏应允许轻松切换到其他时区，并且应始终对电话代表进行培训，以便在提供任何基于时间的信息之前询问他们所处的时区。
它还应该有一个选项，以显示到达时的当地时间。这使您可以无缝，高效地与客户交谈：
1 2 3 4 5 | 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." |
我喜欢GMT +偏移(假设偏移"通常"是用户的时区)。作为一个额外的线索，提供一个工具提示，列出该时区的一些城市(每个半球一个)，或者更详细地解释时区的某个页面的超链接。
正如其他人所提到的，我认为如果应用程序是特定的或本地的，那么您可以省略时区，或做出其他假设。
如果它是全局的，那么您希望一致地存储数据(始终为UTC)，然后转换为显示。此外，您可能希望让用户指定他/她的时区，还可能指定日期和时间格式;要么提供几个静态选项，要么赋予它们指定格式字符串的全部功能，如果它们足够先进的话。
如果您不想为用户提供选项，那么简单的HH：MM TZ或HH：MM GMT +/- H似乎足够了吗？或者您甚至可以只显示服务器的本地时间，然后在脚注或常见问题解答中，说"所有时间都是PST"或其他任何内容。
作为一个用户，我宁愿最大限度的可配置性，但我想我是一个有偏见的，作为程序员。
我认为这无法在没有特定应用的情况下得到明确答复。例如，在同一时区内所有用户的Intranet应用程序中，您通常可以完全省略时区。对于股票市场应用程序，您可能希望相对于市场的时区制作时间。对于社交Web应用程序，您可能希望相对于用户的时区制作时间。我认为适用的一般原则是：
使用Timezone abreviation显示它
代替
1 | 15:18 GMT+1 |
将其显示为中欧时间
1 | 15:18 CET |
人们更习惯于看到自己的时区
多年来，"小"应用突然被全国范围内(在美国，5或6个时区)或全球范围内多次咬伤，如果可能，我总是以UTC格式存储日期时间数据。
正如其他一些帖子所指出的那样，问题就会显现出来。
如果显示日期/时间，并且它与当前用户的位置(和区域设置)相关，则在用户的本地时间显示它。
如果要显示多个日期/时间并且它们与不同位置(可能是不同的区域设置)相关，我发现用户更喜欢以12小时格式查看位置时区中显示的时间。
想想如何打印机票(至少在美国) - 出发和到达时间显示在出发城市和到达城市的时区。最佳行程具有"总行程时间"或显示的持续时间。
好的，所以你想为用户显示语言环境格式的数据：你如何确定语言环境？对于Web应用程序，虽然大多数HTTP标头中都存在区域设置，但您无法始终相信在用户的计算机上正确设置了区域设置。因此，我们几乎总是要求用户设置一个配置文件，其中包含一些数据，我们可以从中确定区域设置(邮政编码，邮政编码，城市/州/国家等)或输入一些信息，让我们了解用户实际驻留(对于Web应用程序或"本机"应用程序)
我没有必要实现这一点，因为通过IP地址的地理位置变得广泛可用，但这也不一定准确。
请注意，当我处理这些应用程序时，我的个人设置几乎总是以24小时格式，UTC，ISO8601结束，所以我知道什么时间显示给我，无论用户在哪里。
最好的办法是以UTC格式存储所有日期/时间信息，然后显示偏移到用户时间的时间。 .NET为此提供了各种支持 - 大多数其他环境也是如此。有人在早上7点在伦敦输入数据应显示为美国东部夏令时凌晨1点或凌晨1点。关于UTC的最好的部分是，当你在没有它的地方时，它避免了夏令时或所有缺乏的东西。韩国，印度与北美的新补偿。
我喜欢24小时，如美国东部时间15:30，但我确信有那些在12H模式下工作的时间。确定这是一个选择。
这是一个非常敏感的情境。我想建立在postos和tvanfosson的建议之上。我不认为需要城市和国家的名称，除了帮助人们设定他们的当地时间，并且可能在对话中设定可能适用于其他地点的时间，因为他们只知道所需的当地时间(不要压倒/分散注意力的巨大挑战)用户对他们来说很杂乱)。
如果位置与时间相关联，那么该位置的日期和时间通常是合适的(例如，当谈到市场关闭，事件，旅行到达和离开等等时)。我赞成这样的想法，即工具提示可用于将其转换为(1)gmt和(2)正在看到界面的用户的明显本地时间。偏移也很有用，也涉及午夜过境的日期。
我也同意时区应该是明确的，因为它可能不是当地时间。此外，即使在没有时区的情况下显示当地时间，我认为工具提示仍然很重要。 (特别是当有人使用笔记本电脑时，可能会保留他们的基地时区设置。)
注重细节：处理夏令时间，夏令时等的时间变化，以及它们之间的区别(不是每个地方都有夏令时，不是每个地方都在同一时间进行更改)和时间点之间(进入特别是未来)。
始终以UTC格式显示时间
NB我不同意这一点。我刚刚将其添加为投票选项。