唯一的服务实例需要根据正在处理的数据更改时区。因此，它可以TZ在处理每个数据之前更改环境变量，等等。
TZ动态更改设置时区和 DST（夏令时）的值的最佳方法是什么？它应该使用 Olson 格式还是 POSIX 格式？可以使用 Olson 格式并关闭 DST 吗？
考虑以下特征：
时区信息的起源：
它检测时区的方式来自于要处理的每个信息，这些信息是：
- 绝对偏移量（相对于 UTC）
- 指示是否必须应用 DST 的标志。请注意，此标志并不说明 DST 是否正在进行，而只是说明当前 DST 设置是否适用。
限制：
- DST 标志假定所有可能的时区只有一种 DST 配置。但是，尽管该服务应该与一组只有一种 DST 的时区一起运行，有些时区有夏令时，有些则没有。
- 该服务不知道
TZ根据 POSIX 格式设置变量的 DST 设置：Mm.w.d/time...
可能的解决方案：
该服务可以期望TZ已经配置了默认时区及其 DST（对于所有其他期望的时区是唯一的），采用 POSIX 格式，如下所示TZ=XXXST3XXXDT,M11.1.1/0,M3.1.1/0
每次服务需要更改时区时，TZ只需调整偏移量并根据 DST 标志的要求清除或保留原始 DST 设置即可更改原始变量。
考虑此默认时区的绝对偏移的示例TZ=XXXST3XXXDT,M11.1.1/0,M3.1.1/0：
- tzoffset=5，dst=假
TZ=XXXST5 - tzoffset=5，dst=true：
TZ=XXXST5XXXDT,M11.1.1/0,M3.1.1/0 - tzoffset=2，dst=true：
TZ=XXXST2XXXDT,M11.1.1/0,M3.1.1/0
该解决方案的缺点：
- 该服务需要在具有自己的
TZ变量的独占（分离）用户中运行 -或任何其他启动过程及其专有变量的方式。 - 该服务无法使用 Olson 时区数据库：如果 DST 设置每年都发生变化，则该系统环境无法使用集中更新的集成 Olson 数据库，需要为该服务的时区进行特定配置（手动或自定义更新）
TZ变量，每年在每个服务器中。 - 该服务将需要一个新的配置来知道如何更改
TZ偏移量，它是绝对的（来自 UTC）还是相对的（来自时区名称）
答案1
这一般是不可能的。绝对偏移量（在某个给定时间点）加上 DST 标志不足以指定特定时区的信息。您没有有关 DST 何时开始和结束的任何信息。您甚至无法确定夏令时当前是否生效。
如果您只想了解给定时间点的 UTC 偏移量，那么您已经知道了。
如果您需要计算任意其他时间点的 UTC 偏移量，则需要更多信息 - 最好是时区的实际 (Olson) 名称。