问题 C ++：你会选择boost :: date_time或icu :: date / time库吗？

如果没有关于您的特定用例和环境的更多信息，就无法给出关于两个库是否优于另一个库的明确答案。正如Xeo所说，分析是解决性能问题的最佳方法。

如果您的用例包含“一般”日期/时间操作（即，您还不知道所需的全部日期/时间操作），您必须做出一些选择。作为 Boost.DateTime文档 解释说，您可以选择以下三种功能：

1. 与挂钟时间完全一致
2. 时刻之间准确的计算
3. 能够处理将来的时间瞬间

没有图书馆可以同时隐含地处理所有这三个的一个原因是，确定在给定时刻是否存在夏令时时间取决于管辖权，其政治问题以及许多其他因素。因此，涉及未来日期的计算可能变得不准确。

在决定这些功能时，您会注意到地理位置和本地化起着重要作用。例如，如果您的日期/时间要求仅需要支持单个区域设置，则没有正当理由将大型ICU库作为依赖项引入。但是，你可能不应该使用Boost.DateTime：作为一个与语言环境无关的库，它忽略了一周的第一天因语言环境而异的事实。此外，Boost.DateTime的时区支持是 破碎;最现代的软件使用 奥尔森数据库 用于时区处理和转换。相反，你应该考虑一下 Boost.Locale 使用Boost处理日期，时间和日历时，

默认情况下，Boost.Locale 使用ICU进行所有本地化任务，但提供了使用非基于ICU的本地化后端的选项。因此，如果您未在其他地方使用Boost（无论出于何种原因）并且需要支持超出当前OS时区的时区以及从UTC转移的时区（忽略夏令时），则仅使用ICU。如果您在其他地方使用Boost，您可以选择Boost.Locale和ICU，但差异很小（最后，ICU包含在内，因此它确实是一个风格和一致性问题）。最后的选择是在你没有在其他地方使用Boost并且你只处理操作系统时区的日期（或使用 先验 已知的UTC偏移量）。在这种情况下，您可能应该使用Boost.Locale.DateTime，但没有ICU支持。

概要

• 不要使用Boost.DateTime有两个原因：（1）它的时区支持被破坏; （2）它忽略了“星期几”计算取决于场所的事实。请改用Boost.Locale.DateTime。
• 如果您在其他地方使用Boost，请继续使用它。它将自动包含基于ICU的本地化后端。您也可以直接调用它们（直接包括ICU），但没有重大区别。
• 如果你是 不 在其他地方使用Boost，那么您的选择取决于用例是否与语言环境无关。如果它与语言环境无关，则可以使用Boost.Locale.DateTime的非基于ICU的本地化后端（例如，std，posix）并避免ICU开销。或者，如果您的用例取决于区域设置，那么您可以使用ICU而不会引入Boost的开销。
• 关于性能：分析是了解的唯一方法。