Answers:
老实说，这是一个网站被多个时区使用时经常看到的一个问题。有许多方法可以克服这场战斗。总结一下总结，关于处理不同时区的因素很多。
大多数网站选择两种不同的解决方案之一来解决此问题：
1）将涉及日期的任何内容都以UTC格式存储在数据库中...，并允许用户在您的网站上进行用户定义的设置，以选择他们所在的时区...或做一些geo-ip-lookup魔术来找出它们在世界上的什么位置，找到合适的时区...然后每次显示日期时，请确保调用本地化所需的任何函数。几乎每种编程语言都有一些使用指定时区显示日期的方法。对于用户插入日期，您还必须反向执行此操作。（以本地时间为准，然后转换回UTC进行数据库存储）这可能是最常见的方法。这也将为您“重新发明轮子”节省大量时间。就匿名访客而言... 您可以A）坚持使用EST / EDT（使用内置函数调用进行适当显示），或者B）恢复为Geo-IP-Lookup内容并根据有根据的猜测选择时区。始终指定要显示日期/时间的时区也是一个好主意。即永远不要说“ 12:00” ...确保它说“ 12:00 EDT”
或2）遵循stackexchange的模型（以及许多其他模型）来显示now和创建帖子之间的差异。即，而不是“在x日期发布” ...您应该做“ x小时前”或“ x天x小时前”等...或将来的日期...“在6天14小时后...”在许多情况下很快变得越来越普遍...但是对于日历类型的时间表而言，它并不理想。
当然...您仍然可以采用两者的某种混合...并且可能甚至需要更进一步，将日期存储为utc ...，还需要为事件存储特定的时区。最终，决定权由您决定。
这就是问题所在：欧盟和美国不能同时打开和关闭DST。今年三月，这些事件之间相差了三个星期。
这是此期间发生的事情。假设您每天都在同一时间举办活动，并且由于您位于美国，因此您将使用美国夏令时调整时间。
Day (2001) United States Europe United Kingdom Global Time delta
March 5th EST 1500 CET 2100 GMT 2000 GMT 2000 +23h
March 6th EDT 1500 CET 2000 GMT 1900 GMT 1900 +24h
March 7th EDT 1500 CET 2000 GMT 1900 GMT 1900 +24h
..............................................................................
March 26th EDT 1500 CET 2000 GMT 1900 GMT 1900 +24h
March 27th EDT 1500 CEST 2100 BST 2000 GMT 1900 +24h
让我们分析所有可能性：
如果您在全球时区中显示时间并将其命名为UTC，这似乎是正确的做法，那么您将使美国客户感到困惑，他们将在不同的UTC时间（昨天晚上8点，今天晚上7点）看到不同的UTC时间。相同的壁钟时间（昨天下午3点，今天又下午3点），然后是您的欧盟客户，他们看不到已发布的时钟更改，但是必须更改其壁钟事件时间。
如果您在全球时区中显示时间并将其命名为GMT，那么除了会迷惑美国客户之外，还会迷惑从GMT切换到BST的英国客户。理解EDT 1500和EST 1400在同一时刻是不合常理的。现在将其转换为BST / GMT（另一个问题是，您将不会在网站的任何部分显示BST时间）。
如果您将时区显示为欧盟时区（我使用CET / CEST来避免GMT / UTC混淆），那么这显然会让您的美国客户感到困惑，他们看到事件时间来回切换了两次，但是却没有墙时钟时间改变自己。尽管您的美国客户可能已经准备好使用第一个开关（毕竟他们必须在同一天更改壁钟），但他们会对后者感到惊讶。
如果您将时区显示为美国时区（例如EST / EDT），则将获得上面解释的确切情况，但会被镜像！
这似乎是一个绝望的情况！在经历了四年艰苦的考验之后（很显然是一年两次），我来解决这个问题的方法如下：“组成一个时区”。
我正好处于上图所示的情况，所以我编了“ NYT”（纽约时区），以便我可以写“ 1500 NYT”来表示“纽约碰巧使用的任何时区的下午3点”。
这样做的好处是，只要用户知道DST waltzer正在发生，他就有一种非常简单的方式来回转换到自己的时区：google“ 纽约时间 ”以了解纽约的时间，然后从那里计算出来。您甚至可以看中并使用基于地理位置的服务，例如time.is/15:00_in_New_York。
需要注意的是，虽然你可以使用time.is时区缩写名称，我劝你不要来，因为他们是很困惑的让人眼前一亮：EST具有相同的时间EDT ‽
您可以通过简短的通知来通知用户有关DST的信息，并链接到适当的时间转换Web服务以帮助人们。理想情况下，所有时间戳都应具有转换为本地时间的选项。
说完所有的一切，您应该意识到我一直无视房间里的大象，这就是您已经实现的“倒计时”解决方案。“在1天2小时45分47秒内”没有什么令人困惑的（而且，如果您认为不需要那么高的精确度，您可能想再考虑一下）。
当然，根据我的经验，我从来没有拥有过非静态文本所无法提供的任何东西，因此我不得不处理上图所示的令人难以置信的混乱（那仅仅是开始！南半球，DST倒退了吗？） ，但对于您的用例来说，这听起来像是最容易混淆的解决方案。一年中，您可能有两个线程询问“在23小时内”和“在25小时内”事件，而通常它从“在24小时内”开始递减计数，仅此而已。