If nl_langinfo() doesn’t support a particular item, it returns the empty
string. We should check for that and return NULL from
g_date_time_format() accordingly, otherwise the user could unwittingly
end up with a formatted date/time which is missing some or all of its
components.
This arose with %r in de_DE, which is unsupported by nl_langinfo()
because Germans almost never write time in 12-hour format.
Add a unit test.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790416
This supports a subset of ISO 8601 since that is a commonly used standard for
storing date and time information. We support only ISO 8601 strings that contain
full date and time information as this would otherwise not map to GDateTime.
This subset includes all of RFC 3339 which is commonly used on the Internet and
the week and ordinal day formats as these are supported in the GDateTime APIs.
(Minor modification by Philip Withnall to change API versions from 2.54
to 2.56.)
https://bugzilla.gnome.org/show_bug.cgi?id=753459
GCC 6.3.1 thinks that tmp is being used uninitialized:
gdatetime.c: In function ‘format_ampm’:
gdatetime.c:2248:7: warning: ‘tmp’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
g_free (tmp);
^~~~~~~~~~~~
It is not an actual problem because the code in question is guarded by
"if (!locale_is_utf8)" and "#if defined (HAVE_LANGINFO_TIME)", and it
does get initialized under those circumstances. Still, it is a small
price to pay for a cleaner build and having actual problems stand out
more prominently.
https://bugzilla.gnome.org/show_bug.cgi?id=785438
I can’t remember whether glong (tv.tv_sec) needs to be explicitly
promoted to gint64 here, or whether C does it automatically. Safer to
make the cast explicit to avoid overflow issues on 32-bit platforms,
where glong is 32-bit.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=783841
GDateTime does overflow checks to see if the timestamp being passed in
is too big to be represented. However, it only does those after
converting from a timestamp to an interval, which involves some
multiplications and additions — and hence can overflow, and cause the
later bounds check to erroneously succeed. This results in a non-NULL
GDateTime being returned which represents completely the wrong date.
Fix the overflow checks (do them earlier) and add some unit tests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=782089
If we have an input parameter (or return value) we need to use (nullable).
However, if it is an (inout) or (out) parameter, (optional) is sufficient.
It looks like (nullable) could be used for everything according to the
Annotation documentation, but (optional) is more specific.
Fallback code for g_date_time_format_locale() fetches translated
strings (such as day and month names) from .mo catalogues via
gettext. These strings always come in UTF-8 encoding, because
that is the encoding that glib sets when it initializes gettext
for itself.
However, the non-fallback code uses nl_langinfo() and expects
its results to be in locale-dependent encoding.
This mismatch can result in UTF-8 strings being converted to UTF-8,
producing gibberish.
Fix this by converting UTF-8 strings to locale-dependent encoding
before using them. Also fix the code that was already doing the locale->UTF-8
conversion to not convert the strings when they are already UTF-8-encoded.
https://bugzilla.gnome.org/show_bug.cgi?id=766092
Add various (nullable) and (optional) annotations which were missing
from a variety of functions. Also port a couple of existing (allow-none)
annotations in the same files to use (nullable) and (optional) as
appropriate instead.
Secondly, add various (not nullable) annotations as needed by the new
default in gobject-introspection of marking gpointers as (nullable). See
https://bugzilla.gnome.org/show_bug.cgi?id=729660.
This includes adding some stub documentation comments for the
assertion macro error functions, which weren’t previously documented.
The new comments are purely to allow for annotations, and hence are
marked as (skip) to prevent the symbols appearing in the GIR file.
https://bugzilla.gnome.org/show_bug.cgi?id=719966
commit 35066ed6c6b51317f49069f2564c547aa309f9f1 replaced entities, but
escaped the replacement text also inside literals, which resulted in the
escaping '\' to also appear in the documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=727320
In Windows development environments that have it, <unistd.h> is mostly
just a wrapper around several other native headers (in particular,
<io.h>, which contains read(), close(), etc, and <process.h>, which
contains getpid()). But given that some Windows dev environments don't
have <unistd.h>, everything that uses those functions on Windows
already needed to include the correct Windows header as well, and so
there is never any point to including <unistd.h> on Windows.
Also, remove some <unistd.h> includes (and a few others) that were
unnecessary even on unix.
https://bugzilla.gnome.org/show_bug.cgi?id=710519
Implement gnulib strftime extensions for the '%z' numeric timezone
format. These are also supported and documented by GNU date(1):
%z +hhmm numeric time zone (e.g., -0400)
%:z +hh:mm numeric time zone (e.g., -04:00)
%::z +hh:mm:ss numeric time zone (e.g., -04:00:00)
%:::z numeric time zone with : to necessary precision (e.g., -04, +05:30)
https://bugzilla.gnome.org/show_bug.cgi?id=707151
The documentation for this function explicitly gives valid
ranges for the arguments and states that out-of-range arguments
will cause NULL to be returned. Only, the code didn't check
the ranges, and crashed instead. Fix that and add a testcase
for invalid arguments. It turns out that the test_z testcase
was providing invalid arguments and relied on g_date_time_new
to return a non-NULL value anyway, so this commit fixes that
testcase as well.
https://bugzilla.gnome.org/show_bug.cgi?id=702674
In non-UTF-8 locales, the translations and nl_langinfo() return values
must be converted to UTF-8 before being returned to the caller.
Likewise, when making a recursive call to expand a format like '%x',
the format string must first be converted to UTF-8.
https://bugzilla.gnome.org/show_bug.cgi?id=668250
We had the 12 hour time format hard-coded to "%02d:%02d:%02d %s" but it
actually changes depending on the locale. Just with the other formats,
use nl_langinfo() if we have it, otherwise fall back on gettext().
Improve a few situations where g_date_time_format() was getting the
padding wrong when displaying alt digits (eg: Arabic numerals) for
formatting time.
We now depend on nl_langinfo (_NL_CTYPE_OUTDIGITn_WC) to do the
conversion, which is very likely glibc-specific, but our previous method
relied on a glibc-specific printf() feature, so no harm done there.
Add a configure check for nl_langinfo (_NL_CTYPE_OUTDIGITn_WC).
Uncomment a few testcases that were failing previously.
https://bugzilla.gnome.org/show_bug.cgi?id=658107
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
