我的应用程序需要自定义时间和日期设置功能。我检查了ICU和boost:：date_time库。从完整性的角度来看，两者似乎都符合我的要求。我想知道两者之间是否有任何偏好，基于什么？哪一个会在表演中得分？
如果没有关于特定用例和环境的更多信息，就无法给出其中一个库是否优于另一个库的明确答案。正如Xeo所建议的，评测是解决性能问题的最佳方式。
如果您的用例包括"通用"日期/时间操作（即，您还不知道所需的全部日期/时间运算），那么您必须做出一些选择。正如Boost.DateTime文档所解释的，您可以在以下三种功能之间进行选择：
- 与挂钟时间完全一致
- 时刻之间的精确计算
- 处理未来时刻的能力
没有一个图书馆能够同时隐含地处理这三个问题的一个原因是，确定夏令时在特定时刻是否存在取决于管辖权、其政治问题和许多其他因素。因此，涉及未来日期的计算可能会变得不准确。
在决定这些功能时，您会注意到地理位置和本地化起着重要作用。例如，如果您的日期/时间要求只需要支持一个区域设置，那么就没有理由将大型ICU库作为依赖项引入。但是，您可能也不应该使用Boost.DateTime：作为一个与区域设置无关的库，它忽略了一周中的第一天因区域设置而异的事实。此外，Boost.DateTime的时区支持被破坏；大多数现代软件使用Olson数据库进行时区处理和转换。相反，在使用Boost处理日期、时间和日历时，您可能应该考虑Boost.Locare。，
默认情况下，Boost.Locare对所有本地化任务使用ICU，但提供了使用非基于ICU的本地化后端的选项。因此，如果您没有在其他地方使用Boost（无论出于何种原因），并且需要支持当前操作系统时区之外的时区和从UTC转换过来的时区（忽略夏令时），则只使用ICU。如果你在其他地方使用Boost，你可以在Boost.Locare和ICU之间进行选择，但差异很小（最终，ICU也包括在内，所以这实际上是一个风格和一致性问题）。当您没有在其他地方使用Boost，并且只处理操作系统时区中的日期（或使用UTC的先验已知偏移量进行日期修改）时，就会出现最后的选择。在这种情况下，您可能应该使用Boost.Locate.DateTime，但不需要ICU支持。
摘要
- 不要使用Boost.DateTime有两个原因：（1）它的时区支持被破坏；以及（2）它忽略了一个事实，即"星期几"的计算取决于地区。请改用Boost.Locate.DateTime
- 如果你在其他地方使用Boost，那么继续使用它。它将自动包括基于ICU的本地化后端。你也可以直接调用它们（通过直接包括ICU），但没有太大区别
- 如果您不是在其他地方使用Boost，那么您的选择取决于用例是否独立于区域设置。如果它与区域设置无关，则可以使用Boost.Locae.DateTime的非基于ICU的本地化后端（，例如、std、posix），以避免ICU开销。或者，如果您的用例取决于区域设置，那么您可以在不引入Boost开销的情况下使用ICU
- 关于性能：评测是了解的唯一途径