我遇到的时区错误

软件开发很难。时区很难。在软件开发中处理时区吗？是啊，再用力一点。

这里有4个时区可能不同的地方；每个案例都有4个个人bug故事。我会为每个故事引用相同的应用程序，也就是我在日常工作中使用和维护的应用程序。这款应用程序适用于墨西哥城时区。

您的应用程序使用默认时区运行。它通常是运行它的服务器所在的时区，但也可以有所不同。

在Java中，您可以在应用程序引导时定义整个应用程序的时区。如果由于某种原因您不想使用服务器的时区，这里是更改它的地方。

这款应用程序可以在许多地方显示对象的创建日期。其中三个地方显示的时间不同；两个错误，一个正确。

其中一个错误是因为我忘了将用户的时区传递给日期格式化程序。速战速决。

第二个错误很奇怪。我找不出原因，所以我把它和正确的做了比较。

但是第三种情况是正确的，因为日期被双重解析了！一次在服务器上，第二次在客户端(浏览器)。

在经历了一些令人头疼的事情之后，我了解到每个版本的Java都附带一个时区数据文件。此文件包括有关世界时区的最新信息，由互联网号码分配机构(IANA)管理。

当政府决定采用或不采用夏令时(DST)时，就会发生时区变化。

2015年，智利决定从季节性DST转变为永久DST，一些JRE版本包含了这一变化。但后来，在2016年，智利决定恢复到以前的样子；季节性的夏令时，而不是永久性的。问题出在哪里？该应用程序使用的JRE版本中有一个带有过时的时区数据文件。

操作系统定义服务器的时区。我一直使用Linux作为生产服务器，它们使用UTC作为默认时区。

如果您需要更改此时区，请确保在应用程序启动之前更改，否则无法反映更改。

我正在迁移构建和部署管道中的一些流程。从每次部署时配置应用程序，到使用HashiCorp的包装程序预建AWS Amazon机器映像(AMI)。

初始配置的一个步骤是将服务器的时区更改为美国/墨西哥城，我知道这一点。因此，我创建了一个bash脚本来更改我们要使用的AMI上的时区。当我在Linux实例上测试该脚本时，它工作得很好。没问题。

我继续在我们的试运行环境中使用这个AMI，我和我的队友都没有注意到一些不对劲的地方。那么，开始制作吧！

什么问题？更新服务器时区的脚本以静默方式失败，我错过了在临时环境中仔细检查它。该应用程序没有使用显式时区，因此它占用了服务器的时区。默认情况下，服务器的时区是UTC，我们需要美国/墨西哥城。我修复了脚本，并确保将应用程序的默认时区更新为预期的时区。

您还可以更改数据库的时区。我使用AWS关系数据库服务(RDS)，默认时区为UTC。您可以通过集群或单个实例的参数组进行更新。

现在我正在迁移我们的数据库。我预料到自己会将数据库的时区更改为美国/墨西哥城，因为应用程序和服务器都有这个时区。系统的每个部分都应该在同一页上，对吗？不对!。

当应用程序和服务器在美国/墨西哥城时，数据库在UTC是完全正常的。这就是它的运作方式。

这个错误并不像前几个错误那样严重，因为我是在我们的临时环境中发现它的。

如果这还不够，您的每个用户可以有不同的时区，在显示时间敏感型数据时，您必须考虑到这一点。

时区是您在开发软件时会发现的最复杂的主题之一。它们本身就很复杂，当你把一些代码混合在一起时就更复杂了。

我希望这些短篇小说能帮助你在将来避免我的错误🙌🏼