我正在设计一个计划 Web 应用程序。我希望事件由多个不同时区和区域设置中的用户添加。挑战在于如何正确呈现这些事件。
因此，举个例子：
如果用户处于EST时区，并且正在查看由另一个用户在PST中添加的网络研讨会事件，我想将事件的实际PST时间转换为观众的本地时间。因此，如果事件安排在太平洋标准时间下午 2 点，则应显示为东部标准时间下午 5 点。
我还想小心，如果有数千个事件可能需要从实际事件时间转换为查看者的本地时间，则性能不会受到打击。
所有的想法和评论都值得赞赏。
断续器
通常，安排未来事件是一个复杂的主题。您必须在将要安排的内容的上下文中进行区分：
事件是否在特定的万能时刻发生？如果是这样，您应该以 UTC 为单位记录事件时间。
例如，每 24 小时运行一次的任务将按 UTC 时间而不是按本地时间进行计划。它可能从某个本地午夜开始，但随着夏令时的变化生效，它可能会在本地时钟的 23：00 或 01：00 运行。
但是，如果事件是由人类安排的，则很可能是以当地时间为准，因此您应该以这种方式记录它。
例如，在东部时间 08：00 召开的会议将始终在该当地时间举行。在冬季，这将是13：00 UTC，而在夏季，它将是12：00 UTC。
因此，在此上下文中，您无法以 UTC 为单位记录计划的开始时间。这是一个非常常见的错误，因为互联网上有很多建议说“始终使用UTC存储”，在这种情况下这是错误的。
相反，您应该存储两个值 - 本地时间（如）及其 IANA 时区标识符（如 ）。您可能还需要存储定期模式或特定日期，具体取决于事件的计划方式。08:00America/New_York
考虑使用Joda Time而不是Java或类。它将使您免于许多头痛。请务必阅读Joda Time文档并了解其工作原理。CalendarDate
Joda Time具有在一个时区和另一个时区之间转换所需的所有功能 - 我相信这是您问题的主要关注点。
请务必制定定期更新时区数据的过程。随着世界各国政府对其时区的法律定义进行更改，每年都会多次推出更新。您不能只部署一次就忘记它。
此外，请确保您了解，由于夏令时，从本地时间到特定UTC时刻的转换并不是一个完美的功能。如果在无效或不明确的本地时间计划事件，则应制定一个策略，以便在应用程序中检测和处理该事件。您可能只是应用一些假设，或者您可能希望不厌其烦地询问用户该怎么做。
例如，如果我将活动安排在东部时间每天凌晨 2：00，则在 2013 年 3 月 10 日，该时间不存在。事件是否应在凌晨 3：00 发生？还是根本不应该发生？
另一个例子，如果我将事件安排在东部时间每天凌晨 1：00，那么在 2013 年 11 月 3 日，该时间会发生两次。事件是否应发生在第一个（夏令时）实例？还是在第二个（标准时间）实例？还是两者兼而有之？我应该假设一个或另一个，还是应该问用户他们的意思？
只有您可以决定要做什么，因为它是您的应用程序。但忽视这个问题可能会导致错误。
事件过去后，如果您愿意，可以按 UTC 格式记录它，也可以使用完整的本地日期时间和偏移量进行记录。任何一个都是可以接受的。这适用于单一的过去事件，只是不适用于重复出现的未来事件。
