时区脱浮

以下是关于减少时区膨胀的一些想法。这是一份草稿，请添加评论、其他选项等。

问题是，当我们打开格式化程序时，我们会读入所有与格式化相关的时区数据，并创建一个包含所有可能输出字符串的大字典。然后用于解析。几个关键问题：

• 1. 即使我们只是格式化（90%以上的情况），我们也会创建这个大数组。

  2. 该阵列的构建成本很高，并且一直存在于缓存中。

让我们再往后退一步。时区的格式根据

• • http://unicode.org/reports/tr35/#Date_Format_Patterns

  • http://unicode.org/reports/tr35/#Time_Zone_Fallback

  • http://unicode.org/reports/tr35/#Timezone_Names

  • http://unicode.org/reports/tr35/#补充Timezone_Data

  • （希望这一切都在一个地方！）

这些对应于z、zzzz、z、zzzz、v、vvvv、v和vvvv模式（其中z和v随日光和标准而变化）。支持这一点的数据包括：

• 1. 将材料粘合在一起的图案，例如｛0｝（｛1｝）

  2. 一些特殊字符串，例如GMT

  3. 特定区域名称

  4. 特定元区域名称

  5. 国家/地区名称

我建议我们这样做。

• 1. 创建TimezoneFormat，继承UFormat/Format（Java vs C++）

     1. 对于格式化，它会格式化分区。format对象具有参数的getters/setter，用于设置上述9个表单（但使用正交参数）。

     2. 对于解析，它从给定点获取一个字符串，并返回一个区域（如果可能的话）和距离。

  2. 重构DateFormat和Timezone，以便每个都有一个TimezoneFormat，并且只在需要时才进行实例化。

  3. 现在更改TimezoneFormatter的实现。

• • 1. 用于格式化

       1. 直接使用资源包中的数据即可；不要把它们复制到字典或列表中。

    2. 用于分析：

• • • 1. 与其把一本大字典放在一起，它是一堆小字典的交叉产物，不如放几个小字典来对应特定的名字。这些词典可以快速加载，而且体积较小。

      2. 解析时，尝试多次使用不同的可能粘合模式并解析子组件。如果有多个匹配项，则选择最长的匹配项。

示例：分析太平洋时间（加拿大）时

• • 检查Z格式（例如-0800）-不匹配，请尝试下一步

  • 解析GMT{0}-不匹配，请尝试下一步

  • 分析特定时区-不匹配，请尝试下一步

  • 分析元区域标准-不匹配，请尝试下一步

  • 解析metazone generic-successful，记住America/Los_Angeles，还有我们走了多远；试试下一步

  • 分析元地带通用+国家/城市-成功，现在最长，所以记住，美国/温哥华和我们走了多远；试试下一步

  • 分析回退格式，使用国家/城市和通用元区域-不匹配，请尝试下一步

  • 返回时间最长（美国/温哥华）以及我们走了多远。

以上可以进行优化，但我们可能不需要太多，因为绝大多数故障都会提前失败（因此成本不高）。这将使解析速度稍慢，但该操作通常不是时间关键型的。反过来，它降低了初始化时间，并大大减少了当前的内存需求。