https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118811
--- Comment #15 from Nicholas Williams <nicholas at nicholaswilliams dot net>
---
(In reply to Jonathan Wakely from comment #12)
> As a workaround you can add this non-static data member to your
> BackgroundThread class:
>
> namespace Logger
> {
> class EXPORT BackgroundThread
> {
> // ...
> std::chrono::tzdb_list::const_iterator tzdb =
> std::chrono::get_tzdb_list().begin();
> };
> }
>
> The iterator contains a shared_ptr which shares ownership with the
> chrono::tzdb at the front of the tzdb_list. While that iterator exists, the
> tzdb object will not be destroyed even if the global shared_ptr inside
> libstdc++ is destroyed. (This is a GCC extension, the C++ standard doesn't
> require this behaviour of the iterator extending the tzdb lifetime).
>
> If you update the system's zoneinfo (i.e. tzdata) files and then call
> chrono::reload_tzdb() while the application is running, then subsequent
> calls to chrono::get_tzdb_list() will access a different instance of
> chrono::tzdb, and the const_iterator will not extend the lifetime of the
> correct chrono::tzdb object. You can update the iterator to refer to the new
> front of the list if needed.
Fascinating. I'll give that a try. I'm unsure if we could incorporate this
workaround in our code. We may just have to stick with gmtime_r and
std::put_time, etc. for now.
