summaryrefslogtreecommitdiff
path: root/gio/gio.h
diff options
context:
space:
mode:
authorColin Walters <walters@verbum.org>2011-08-19 03:27:16 -0400
committerColin Walters <walters@verbum.org>2011-08-22 11:12:37 -0400
commit5b68b49b2072c371c72ee96175e3d6a727eb5e8b (patch)
tree68b1d4c91be9cb1c038558ca6f68e2b12fa65871 /gio/gio.h
parent5fbf3c93b236970e1c68be05c08322099a51e6bf (diff)
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
Diffstat (limited to 'gio/gio.h')
-rw-r--r--gio/gio.h1
1 files changed, 0 insertions, 1 deletions
diff --git a/gio/gio.h b/gio/gio.h
index 9281ddef0..f0bc5500f 100644
--- a/gio/gio.h
+++ b/gio/gio.h
@@ -119,7 +119,6 @@
#include <gio/gtcpwrapperconnection.h>
#include <gio/gthemedicon.h>
#include <gio/gthreadedsocketservice.h>
-#include <gio/gtimezonemonitor.h>
#include <gio/gtlsbackend.h>
#include <gio/gtlscertificate.h>
#include <gio/gtlsclientconnection.h>