Explicitly mention C99's strftime() in the documentation for
g_date_time_format() as the one that we aim for compatibility with.
Specifically list the formats we do not support as well as the extra
ones that we borrow from glibc.
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.
%N is not specified in any standards document, but we use it to display
the number of microseconds.
The fact that our our current implementation of it is nearly useless
(since it does not zero-pad) coupled with the high chance that a future
version of the C standard may specify it with another meaning means that
we should drop it.
https://bugzilla.gnome.org/show_bug.cgi?id=658061
%V represents the ISO 8601 week number of the current year as a
decimal number, range 01 to 53, where week 1 is the first week
that has at least 4 days in the new year
https://bugzilla.gnome.org/show_bug.cgi?id=658061
This makes the source efficient on Linux.
Tested on Fedora 15 x86_64 + updates, kernel-2.6.40-4.fc15.x86_64
Also tested fallback code for unsupported flag TFD_TIMER_CANCEL_ON_SET
on kernel 2.6.38.
https://bugzilla.gnome.org/show_bug.cgi?id=655129
Several different codebases in GNOME want to implement wall clocks.
While we could pretty easily share a private library, it's not a
substantial amount of code, and GLib already has a lot of the
necessary system-specific detection and handling infrastructure.
Note this initial implementation just wakes up once a second in the
cancel_on_set case; we'll add the Linux-specific handling in a
subsequent commit.
https://bugzilla.gnome.org/show_bug.cgi?id=655129
This makes g_date_time_format() react to LC_TIME, which is
what people expect.
Translators: this change means that the GDateTime strings
are only used when the C library does not already provide
suitable translated strings for these (month names, etc).
Make g_date_time_format() support some useful format modifiers from
strftime(). This commit adds support for the POSIX 'O' modifier
(alternative digits), as well as the -/_/0 padding modifiers, which
are a GNU strftime() extension.
https://bugzilla.gnome.org/show_bug.cgi?id=648678
The 12h mode hour format is computed by taking the
24h mode hour format modulo 12.
The conversion results in 12 noon getting erroneously
converted to 0.
This commit makes noon get the same special handling
as midnight.
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.
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
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
