GTimeZoneMonitor: Revert addition of this class
authorColin Walters <walters@verbum.org>
Fri, 19 Aug 2011 07:27:16 +0000 (03:27 -0400)
committerColin Walters <walters@verbum.org>
Mon, 22 Aug 2011 15:12:37 +0000 (11:12 -0400)
commit5b68b49b2072c371c72ee96175e3d6a727eb5e8b
tree68b1d4c91be9cb1c038558ca6f68e2b12fa65871
parent5fbf3c93b236970e1c68be05c08322099a51e6bf
GTimeZoneMonitor: Revert addition of this class

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
12 files changed:
docs/reference/gio/gio-sections.txt
docs/reference/gio/gio.types
docs/reference/glib/glib-sections.txt
gio/Makefile.am
gio/gio.h
gio/gio.symbols
gio/gtimezonemonitor.c [deleted file]
gio/gtimezonemonitor.h [deleted file]
glib/glib.symbols
glib/gtimezone.c
glib/gtimezone.h
glib/tests/gdatetime.c