Question

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?

Answer 1

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:

1. Exact agreement with the wall-clock time
2. Accurate calculations between time instants
3. Ability to handle time instants in the future

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

• Don’t use Boost.DateTime for two reasons: (1) its time zone support is broken; and (2) it ignores the fact that “day of week” calculations depend on the locale. Use Boost.Locale.DateTime instead.
• If you’re using Boost elsewhere, then continue using it. It will automatically include the ICU-based localization back-ends. You may alternatively invoke them directly (by directly including ICU), but there’s no major difference.
• If you’re not using Boost elsewhere, then your choice depends on whether the use case is locale-independent. If it’s locale-independent, you can use Boost.Locale.DateTime’s non-ICU-based localization backends (e.g., std, posix) and avoid the ICU overhead. Alternatively, if your use case depends on locale, then you can use ICU without introducing Boost’s overhead.
• On performance: profiling is the only way to know.