我的 BST 时区晚一小时吗？

Question 1

BST不被识别为时区名称。它在输出中用作缩写，但不能使用它来指定时区。大多数程序不会检查时区名称，如果无法识别时区名称，则会默认默认为 GMT。

BST、CET、EST 等缩写并不总是明确定义，有时甚至含糊不清（是北美标准时间还是澳大利亚东部标准时间？）。它们仅在给定区域中有意义，而时区配置通常适用于全球范围内使用。此外，像 BST 这样的缩写实际上并不指定时区，而仅指定一年中某个时区的时间（英国，夏令时有效）。因此，您应该使用明确的名称，其中大多数都遵循大陆/城市的模式。在典型的 Linux 系统上，我想在许多其他 Unix 变体上也是如此，您可以通过查看目录来查看哪些缩写可用/usr/share/zoneinfo。

GMT因此，不要在冬天和BST夏天使用，而是使用Europe/London.

Answer

BST不被识别为时区名称。它在输出中用作缩写，但不能使用它来指定时区。大多数程序不会检查时区名称，如果无法识别时区名称，则会默认默认为 GMT。

BST、CET、EST 等缩写并不总是明确定义，有时甚至含糊不清（是北美标准时间还是澳大利亚东部标准时间？）。它们仅在给定区域中有意义，而时区配置通常适用于全球范围内使用。此外，像 BST 这样的缩写实际上并不指定时区，而仅指定一年中某个时区的时间（英国，夏令时有效）。因此，您应该使用明确的名称，其中大多数都遵循大陆/城市的模式。在典型的 Linux 系统上，我想在许多其他 Unix 变体上也是如此，您可以通过查看目录来查看哪些缩写可用/usr/share/zoneinfo。

GMT因此，不要在冬天和BST夏天使用，而是使用Europe/London.

Question 2

date正如 @Gilles 所说， BST 是在/上输出的东西date +%Z，告诉用户这是英国夏令时间日期（所以 GMT+1）而不是定义时区的东西，而不是可以用于的东西$TZ。

BST 对于英国用户来说意义重大。当英国用户看到时14:00 BST，他们知道时间戳是指英国大陆夏令时 14:00（即 UTC 13:00）。这些 3-4 个字母的代码在英国、美国和其他一些英语国家广泛使用，因此会出现在date这些国家的默认输出中（en_GB.UTF-8例如在区域设置中）。另一方面，大多数法国用户不知道是什么14:00 CEST意思（即使CEST指的是中欧夏令时间，适用于法国夏季的 GMT+2），因此您会注意到，当日期指定时区时，它们宁愿包含 UTC 偏移量，而不是CET/CEST那里（如mardi 2 mai 2017, 13:34:09 (UTC+0200)）。

该$TZ变量并不意味着包含那些 3-4 个字母的代码。它包含一些东西定义/指定时区，您所在的区域。应用程序使用它来了解任何时间点与 UTC 的偏移量、何时在冬季和夏季时间之间切换以及将显示冬季和夏季时间的代码（如果有）给用户（对于那些对其来说很重要的用户）。

为此，您可以设置TZ为某些系统定义的时区规范。就像TZ=:Europe/London（尽管许多系统也接受TZ=Europe/London），或者包含TZ完整的规则（尽管这些规则是有限的）。

例如，如果我TZ=:Europe/London在我的系统上使用，那么规则将从中读取/usr/share/zoneinfo/Europe/London。

例如，该文件将指定自 1996 年以来，从 10 月最后一个星期日凌晨 2 点 UTC 到 3 月最后一个星期日（名称为 GMT 表示“格林威治标准时间”）与 UTC 的偏移量为 0，其他为 1（名称为 BST）代表“英国夏令时间”），而从 1970 年（0 Unix 时间）到 1972 年，全年均为 1，名称为 BST，代表“英国夏令时间”标准时间”。

您已经可以看到，使用 BST 作为时区规范是没有意义的。首先，它在不同的时间点意味着不同的事情，即使我们只考虑当前纪元，它也只是夏季时间的代码，因此不能用作全年的时区规范。

现在，您还可以包含TZ完整的规则。例如，对于 70 年代初的“英国标准（非夏季）时间”，您可以使用最简单的规范形式：

TZ=BST-1

它指定始终位于 UTC 以东 1 小时的时区，并且date +%Z始终返回BST。该时区对于 70 年代初期的英国大陆以及自 1972 年以来的夏季时间来说是正确的，但对于 1972 年以来的冬季时间来说是正确的（我们无法预测未来）。

或者您可以使用当前规则的完整规范：

TZ=GMT0BST,M3.5.0/1:00:00,M10.5.0/2:00:00

这表示一年中有两个时间段，一个时间段的名称为 GMT，偏移量为 0，另一个时间段的名称为 BST，偏移量为 1（未指定时，隐含为上面的 0+1），其中从一个时间段到另一个时间段的切换处于打开状态3 月 (3) 的最后 (5) 个星期日 (0) 1:00:00 UTC，并于 10 月最后一个星期日 2:00 返回。

再次强调，TZ 从 1996 年一直有效，但不一定有效。例如，对于 1970-01-01 00:00:00 UTC（0 Unix 纪元时间，伦敦本地时间为 1:00:00 BST（英国标准时间））：

$ TZ=:Europe/London date -d @0
Thu  1 Jan 01:00:00 BST 1970
$ TZ=GMT0BST,M3.5.0/1:00:00,M10.5.0/2:00:00 date -d @0
Thu  1 Jan 00:00:00 GMT 1970

根据 POSIX，行为

TZ=BST-1定义明确（如上所述）
TZ=BST（或TZ=GMT/ TZ=UTC/ TZ=Europe/London）未指定。
TZ=:BST/TZ=:Europe/London是实施定义。也就是说，系统旨在支持它并记录它的作用，尽管 POSIX 没有告诉我们它做了什么。

在上面的第三种情况中，在 GNU 系统（我相信大多数其他类 Unix 系统）上，当TZ以开头时:，后面的内容将被视为时区定义文件的路径。在 GNU 系统的情况下，当被省略时也是如此:（即使该值形成一个有效的时区规范，如UTC0，但通常不应该存在这样的文件，尽管我可以在我的系统上看到一些例外，这使得它成为非 POSIX 系统（例如TZ=CST6CDT date -d 1943-01-01 +%Z输出CWT而不是CST因为有一个/usr/share/zoneinfo/CST6CDT文件¹定义了战时在那段时间））。

该路径通常是相对路径，在这种情况下它是相对的$TZDIR（或者像通常情况下未设置/usr/share/zoneinfo时的某些默认值）。$TZDIR出于安全原因，在权限升级上下文中（例如在 setuid 上下文中），将忽略$TZDIR带有组件的绝对路径或相对路径。..

因此，通常在 GNU 系统上， , 与通常查找文件TZ=:BST相同。如果未找到（就像这种情况，因为不可能识别时区定义），它通常会假定 UTC 时间和时区名称（如输出中所示）。TZ=BST/usr/share/zoneinfo/BSTBSTdate +%ZBST

¹CST6CDT诸如WET、CET、 ...之类的MET都是另一个时代的残余。 1993年底，TZ数据库（现在由 IANA 维护）改变了从使用临时（且通常是不明确的）名称（如MET、GB-Eire、WET）到Area/City该城市是该区域适用的人口最多的城市（在发布时）（区域是大陆/海洋等大面积区域）。对于英国大陆，您过去使用GB-Eire（不是 WET），现在（自 1993 年以来）使用Europe/London. GB-Eire（如WET）仍然可用于向后兼容（GB-Eire现在链接到Europe/London，而WET被定义为在冬季使用 UTC 和欧盟 DST 规则的区域（英国自 1996 年以来才遵循欧盟规则，英国现在已离开欧盟，没有人能说出未来会怎样））但现在不应该在新部署中使用。

Answer