C++: 你会选择 boost::date_time 还是 icu::date/time 库？
我的应用程序需要自定义时间和日期设置功能。我检查了 ICU 和 boost::date_time 库。从完整性的角度来看，两者似乎都满足我的要求。我想知道两者之间是否有任何偏好，依据是什么？哪一个会在表现上得分？
My application requires custom time and date setting capabilities. I checked both ICU and boost::date_time libraries. Both appears to meet my requirements from a completeness point of view. I would like to know if there is any preference between the two and on what basis? which one will score on performance?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果没有有关您的特定用例和环境的更多信息，就无法给出关于两个库是否优于另一个库的明确答案。正如 Xeo 所建议的，分析是解决性能问题的最佳方法。
如果您的用例包括“常规”日期/时间操作（即，您还不知道所需的全部日期/时间操作），则您必须做出一些选择。正如 Boost.DateTime 文档 解释说，您可以在这三种功能之间进行选择：
没有库可以同时隐式处理所有这三种功能的原因之一是确定某一特定时刻是否存在夏令时取决于司法管辖区、其政治问题以及许多其他因素。因此，涉及未来日期的计算可能会变得不准确。
在选择这些功能时，您会注意到地理位置和本地化发挥着重要作用。例如，如果您的日期/时间要求仅需要支持单个区域设置，则没有合理的理由引入大型 ICU 库作为依赖项。但是，您可能也不应该使用 Boost.DateTime：作为与区域设置无关的库，它忽略了一周的第一天因区域设置而异的事实。此外，Boost.DateTime 的时区支持已损坏< /a>;大多数现代软件使用 Olson 数据库 进行时区处理和转换。相反，您可能应该考虑 Boost.Locale 当使用 Boost 处理日期、时间和日历时。
默认情况下，Boost.Locale 使用 ICU 执行所有本地化任务，但提供使用非基于 ICU 的本地化后端的选项。因此，如果您没有在其他地方使用 Boost（无论出于何种原因），并且需要支持当前操作系统时区之外的时区以及从 UTC 转移的时区（忽略夏令时），则仅使用 ICU。如果您在其他地方使用 Boost，则可以在 Boost.Locale 和 ICU 之间进行选择，但差异很小（最终包括 ICU，因此这实际上是一个风格和一致性问题）。当您不在其他地方使用 Boost 并且仅处理操作系统时区中的日期（或使用与 UTC 的先验已知偏移量进行日期修改）时，就会出现最终选择。在这种情况下，您可能应该使用 Boost.Locale.DateTime，但没有 ICU 支持。
总结
Without more information about your specific use case and environment, there's no way to give a definitive answer as to whether either library out-performs the other. As Xeo suggested, profiling is the best way to address performance concerns.
If your use case includes "general" date/time manipulation (viz., you don't yet know the full spectrum of date/time operations that you need), there are a few choices you must make. As the Boost.DateTime documentation explains, you have a choice between these three capabilities:
One reason why no library can implicitly handle all three simultaneously is that the determination of whether daylight savings time exists at a given time instant depends on the jurisdiction, its political issues, and a host of other factors. As such, calculations that involve future dates may become inaccurate.
In deciding between these capabilities, you'll notice that geography and localization play an important role. If, for example, your date/time requirements need only support a single locale, there's not justifiable reason to introduce the large ICU library as a dependency. But, you probably shouldn't use Boost.DateTime, either: as a locale-agnostic library, it ignores the fact that the first day of the week varies by the locale. Additionally, Boost.DateTime's time zone support is broken; most modern software use the Olson database for time zone processing and conversions. Instead, you should probably consider Boost.Locale when using Boost to work with dates, times, and calendars.,
By default, Boost.Locale uses ICU for all localization tasks, but provides the option to use non-ICU-based localization back-ends. So, if you're not using Boost elsewhere (for whatever reason) and need to support time zones beyond the current OS time zone and time zones shifted from the UTC (ignoring daylight savings time), then use only ICU. If you're using Boost elsewhere, you have a choice between Boost.Locale and ICU, but the differences are minimal (in the end, ICU is included, so it's really a stylistic and consistency question). The final choice arises when you're not using Boost elsewhere and you're only dealing with dates in the OS's time zone (or date modifications using an a priori known offset from the UTC). In that case, you should probably use Boost.Locale.DateTime, but without the ICU support.
Summary