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