mirror of
https://gitlab.gnome.org/GNOME/glib.git
synced 2024-12-28 08:26:14 +01:00
5b68b49b20
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 |
||
|---|---|---|
| .. | ||
| reference | ||
| debugging.txt | ||
| macros.txt | ||
| Makefile.am | ||