glib is trying to move toward using microseconds-in-gint64 as its
universal time format.
No real API breaks here since GTimeSpec is new this unstable release
series.
The code was designed to deal with any granularity of timer and due to
the use of GTimeVal/GTimeSpec, the math for this gets extremely
confusing.
From a practical standpoint, we only ever have a granularity of seconds.
Take advantage of that fact in the code and vastly simplify the math.
Add some helpers for freeing a linked list along with its elements by
providing a GDestroyNotify to call on each of them.
Add a test.
Based on a patch from Cosimo Cecchi.
Avoid acquiring the lock on the instance on the case of deserialising a
child. We know that it is safe to do this unlocked because a serialised
child will never become unserialised.
Closes#626320
Make g_get_user_data_dir() return the CSIDL_LOCAL_APPDATA folder on
Windows, and not CSIDL_PERSONAL. On Windows 7, that corresponds to the
subfolders AppData\Local vs. Documents under the profile ("home")
folder. This matches what Qt does, for instance, and has been widely
requested.
Also make g_get_user_config_dir() return this and not the (roaming)
CSIDL_APPDATA folder. The reason for this change is that it would be
surprising and hard to justify if g_get_user_data_dir() returned the
local application data folder while g_get_user_config_dir() would
return the roaming one. Nothing in the function names or the XDG specs
suggests that any roaming vs. local dichotomy would be involved.
Document the new semantics and the fact that these two functions now
return the same directory on Windows.
Note that in reality, code that really truly wants to support Windows
as well as possible probably will not use these GLib functions anyway,
but Win32 APIs directly to be sure what it is doing...
Should hopefully satisfy complaints in bug #620710 and related bugs.
One of the GVariant test cases allocates a pair of character arrays on
the stack and then passes them to functions that assume that they will
be aligned to a multiple of two.
This is not the case for some versions of GCC (4.0.3 on PowerPC).
Make g_variant_byteswap() merely return a new reference on the given
value in the event that we know that byteswapping will have no effect
(ie: types which have no alignment requirement).
This fixes a somewhat complicated interaction between GVariant,
GSettings and GVDB on big endian machines: GSettings assumes that it
can unref values returned from GVDB without losing access to the
underlying data. This only works if the underlying data is in the
mapped file -- not a freshly-allocated buffer that GVariant byteswapped
into.
Adds a new function g_main_context_invoke() (and _full() variant).
This function takes a main context, a function and a user_data. If the
main context is already acquired in the current thread, the function is
invoked directly. If the main context is the default main context of
the current thread and it can be acquired then the function is invoked
directly while the context is owned. Otherwise, the function is
scheduled as an idle on the context.
No functionality changes here.
Vastly simplify the algorithm for calculating the day of the week.
Fix the documentation (which is incorrectly stating that 1 means
Sunday) and clarify that the number we return is in line with ISO 8601
week day numbering.
Emmanuele suggested adding G_GNUC_WARN_UNUSED_RESULT to all of the
g_date_time_add_* functions to help deal with the situation where people
may mistakenly believe that these functions are inplace modifiers.
Using the internal pcre has the side effect of exposing gregex.c to
glib.h. When we use the system one, we lose that, so we need to
explicitly include the things we use (glist, gatomic, etc..)
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
The current msgctxt string 'GDateTime" lead to the unability to
differentiate between the full and abbreviated name for May.
Therefore, the msgctxt strings have been changed to
'full month name'
'abbreviated month name'
'full weekday name'
'abbreviated weekday name'
This is a string change, but all translations have been updated
using an sed script.
Bug 629429
This is a vtable structure and very likely the user has allocated it in
static storage and wants it to be const. Since we never modify it, no
harm is done to us to have it const.
Closes bug #629328.
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>
Previously, the format string was iterated many times by
walking to the given offset in the string repeatedly.
This patch instead walks the string using g_utf8_next_char().
Additionally, the character for lookups was a char and could
loose content. This uses gunichar instead.
https://bugzilla.gnome.org/show_bug.cgi?id=50076
These were left over from when the inline functions where implemented
as macros. They are no longer needed and where clashing with the
global __year anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=50076
Don't call LoadLibrary() on shell32.dll or kernel32.dll. kernel32.dll
is always loaded. Shell32.dll is also already loaded as glib links to
functions in it. So just call GetModuleHandle() on them.
For mlang.dll in win_iconv.c and winhttp.dll in gwinhttpvfs.c, always
try loading them from a complete path, from the Windows system
directory.
Use the "tool help" API to enumerate modules in gmodule-win32.c. It is
present in all Windows versions since Windows 2000, which is all we
support anyway. Thus no need to look that API up dynamically. Just
link to it normally. We can bin the fallback code that attempts to use
the psapi API.
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>
