Our implementation of %W is incorrect. Nobody should want to use this
format anyway and the implementation is non-trivial, so rip it out
rather than fixing it.
Remove the testcase for %W as well.
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
If a DateTime gets modified to cross the DST state from its previous
state then we want to update the DateTime to compensate for the new
offset.
In other words, if we have a DateTime defined as:
DateTime({ y: 2009, m: 8, d: 15, hh: 3, mm: 0, tz: 'Europe/London' });
and we add six months to it, the hour must be changed to 60 minutes
behind, as the DST comes into effect.
https://bugzilla.gnome.org/show_bug.cgi?id=50076
Otherwise we'll have to do:
dt = g_date_time_new_full (Y, M, D, h, m, s, tz);
tmp = g_date_time_add_usec (dt, usec);
g_date_time_unref (dt);
dt = tmp;
With its additional allocations.
https://bugzilla.gnome.org/show_bug.cgi?id=50076
Timezone handling is complicated. Really complicated.
In order to simplify it a little bit, we need to expose the GTimeZone
structure.
First of all, we allow creating time zone information directly from the
offset and the DST state, and then pass it to the g_date_time_new_full()
constructor. We also need to clean up the mess that is UTC-vs.-localtime
for the other constructors.
We also allow creating a GTimeZone from the Olson zoneinfo database
names; a time zone created like this will be "floating": it will just
reference the zoneinfo file - which are mmap()'ed, kept in a cache and
refcounted. Once the GTimeZone has been associated with a GDateTime, it
will be "anchored" to it: the offset will be resolved, as well as the
DST state.
https://bugzilla.gnome.org/show_bug.cgi?id=50076
Use Proleptic Gregorian calendar instead of the Julian calendar
as the internal representation.
https://bugzilla.gnome.org/show_bug.cgi?id=50076
Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
The current implementation of g_date_time_add_full() creates multiple
GDateTime temporary objects and unrefs them immediately; even with the
slice allocator this could result in a performance bottleneck,
especially if the atomic integer operations fall back to slow paths.
We can isolate the components of the add_full() operation and create
internal modifiers that operate on an existing GDateTime; this brings
down the number of GDateTime copies created from six to one.
While at it, the test suite for add_full() should have more checks for
roll-over of months and days.
Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
GDateTime is an opaque data type containing a date and time
representation. It's immutable once created and reference
counted.
https://bugzilla.gnome.org/show_bug.cgi?id=50076
Based on the code by: Christian Hergert <chris@dronelabs.com>
Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
