使 CloudKitty 具备时区感知能力

关联的故事： https://storyboard.openstack.org/#!/story/2005319

目前，CloudKitty 并不具备时区感知能力，并且每个时间戳都被认为是 UTC 时间。为了改善用户体验，避免混淆和潜在的错误（在进行时间对象转换时），CloudKitty 应该具备时区感知能力。

问题描述

在内部，CloudKitty 操作的是不带时区信息的 datetime 对象和时间戳。每个代表某个时间点的对象都被认为是 UTC 时间。这对于用户来说可能令人困惑（他们期望其数据的的时间戳在其当前时区中），并且也可能成为错误的来源：一个 datetime 对象（转换为 iso8601 格式的时间戳）不包含时区信息。 另一种 API 如何解释这种字符串没有保证：作为 UTC，还是作为 API 的本地时间？

提议的变更

为了确保 CloudKitty 关于时区的行为，应应用以下几点

  • 所有 datetime 对象必须具备时区信息。

  • CloudKitty 只能操作 datetime 对象。接受多种类型对象作为包含时间信息的参数的函数或接口必须进行更改，以便仅接受具备时区信息的 datetime 对象。

  • 与 iso8601 时间戳或 unix 时间戳的转换必须在接口级别完成。这意味着到/从具备时区信息的 datetime 对象的转换只能由 CloudKitty 的 HTTP API 和不同的驱动程序（存储、提取器、收集器、消息传递…）完成，并且仅当不支持这种类型时才进行转换。

  • API 获取的任何不带时区信息的对象都应被视为 UTC 时间，并使其具备时区信息，并发出警告。

  • 不同 SQL 数据库之间对具备时区信息的对象的处理方式不一致。因此，存储状态仍然将不带时区信息存储，并将存储为 UTC 时间。存储状态驱动程序将负责使对象具备/不具备时区信息，并且仅提供/接受具备时区信息的 datetime 对象。为了避免复杂的迁移和不一致性，相同的规则将适用于数据帧的时间戳：它们将作为不带时区信息的时间戳存储，并被视为 UTC 时间。存储驱动程序将负责转换。

  • 查询 v2 API 的客户端函数将发送带有时区信息的 iso8601 时间戳。如果 CLI 参数中未提供时区信息，则它们将被视为本地时间，并添加相应的时区信息。

为了方便起见，目前不支持微秒，并且所有 datetime 对象中的微秒都将设置为 0。

备选方案

  • 保持代码不变，并在文档中明确说明所有内容均为 UTC 时间。但这并不能防止将不带时区信息的数据发送到其他 API 时出现意外行为。

数据模型影响

无，存储状态模型不会被修改。

REST API 影响

无。

安全影响

无。

通知影响

无。

其他最终用户影响

对于 v2 API 端点，传递给客户端的不带时区信息的时间戳将被客户端视为本地时间，并相应地更新时区信息。

性能影响

无。

其他部署者影响

无。升级不会影响状态存储或数据帧存储，因为不需要存储迁移。因此，现有数据不会受到影响。

开发人员影响

清晰且更严格的规则将减少在新功能实现中潜在的时间相关错误。

实现

负责人

Gerrit 主题

时区感知

主要负责人

peschk_l

其他贡献者

无

工作项

以下某些点高度相互依赖，可能需要在同一个提交中实现

  • 从代码库中删除 Unix 时间戳的使用，以便仅在内部操作 datetime 对象。

  • 将时区信息添加到内部操作的所有 datetime 对象。

  • 使查询 v2 API 的客户端函数具备时区感知能力。

依赖项

  • python-dateutil：提供标准库 datetime 模块扩展的库。

测试

在 v2 API 具有更多端点之前，单元测试就足够了。应使用带有和不带有时间戳中时区信息的 Tempest 测试来测试 v2 API 端点，以确保 API 具有预期的行为。

文档影响

v2 API 文档和客户端文档将包含有关其对具备/不具备时区信息的时间戳的处理方式的描述。

参考资料

无。