The main rationale for adding it was to avoid having gnome-shell
mmap'ing /etc/localtime once a second.  However, we can just as easily
run inotify there, and given no one else was clamoring for a way to
detect when the time zone changes, I don't see a need for public API
here - at least not yet.

In the bigger picture, I just don't believe that the vast majority of
applications are going to go out of their way to instantiate and keep
around a random GTimeZoneMonitor class.  And if they do, it's has the
side effect that for other bits of code in the process, local GDateTime
instances may start varying again!

So, if code can't rely on local GDateTime instances being in a
consistent state anyways, let's just do that always.  The
documentation now says that this is the case.  Applications have
always been able to work in a consistent local time zone by
instantiating a zone and then using it for GDateTime constructors.

We fix the "gnome-shell stats /etc/localtime once a second" issue by
using timerfd (in glib) and inotify (in gnome-shell).

https://bugzilla.gnome.org/show_bug.cgi?id=655129