This doesn't appear to work reliably on s390x and ppc64, returning
the results that were expected without %E or intermittently crashing.
It seems that on little-endian 64-bit, the intptr_t returned by the
undocumented _NL_TIME_ERA_NUM_ENTRIES correctly has the number of entries
in its low-order half (at the time of writing, 0x0000'0000'0000'000b for
Japan), but on big-endian 64-bit, it has the number of entries in its
high-order half instead (for example 0x0000'000b'0000'0000 for Japan),
with the low-order half being all-zero or possibly uninitialized.
Making this reliable will require some sort of defined API from glibc.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/3225
Bug-Debian: https://bugs.debian.org/1060735
Signed-off-by: Simon McVittie <smcv@collabora.com>
I wrote the changes before clarifying the copyright status of my
contract with the GNOME Foundation, and forgot to update them.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3119
The `%E` modifier causes dates to be formatted using an alternative era
representation for years. This doesn’t do anything for most dates, but
in locales such as Thai and Japanese it causes years to be printed using
era names.
In Thai, this means the Thai solar calendar
(https://en.wikipedia.org/wiki/Thai_solar_calendar). In Japanese, this
means Japanese era names
(https://en.wikipedia.org/wiki/Japanese_era_name).
The `%E` modifier syntax follows what’s supported in glibc — see
nl_langinfo(3).
Supporting this is quite involved, as it means loading the `ERA`
description from libc and parsing it.
Unit tests are included.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Fixes: #3119
The alt-digits are loaded from `nl_langinfo()` in a `GOnce` section,
which means `nl_langinfo()` is not re-queried after the process changes
locale (if that happens).
So, change the `GOnce` to a mutex and store the locale of the alt-digits
alongside them. This will introduce contention when calling
`format_number()` is called, but how often are multiple threads trying
to format dates at the same time?
If this does get highlighted as a performance problem, the other
approach I considered was a `GPrivate` struct containing all the
locale-specific cached data. That comes at the cost of using a
`GPrivate` slot (although that’s only particularly expensive on Windows,
and the locale code is quite different for Windows, so perhaps that
could be avoided entirely). It does mean that all locale printing could
be lock-free and still safely update cached data on a locale change.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Padding numbers with a typical space character doesn't align them well
because it has a different size. Instead, we need to use the "U+2007"
figure (numeric) space that has the same size as a numerical digit.
This is only visible when using the `tnum` font feature that
makes numbers monospace.
Closes#2655
These have all been added manually, as I’ve finished all the files which
I can automatically detect.
All the license headers in this commit are for LGPL-2.1-or-later, and
all have been double-checked against the license paragraph in the file
header.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
This introduces no functional changes, but reworks the array indexing so
that scan-build has a better idea about the array bounds. This squashes
the scan-build warning:
```
../../../../source/glib/glib/gdatetime.c:2292:20: warning: The left operand of '>=' is a garbage value [core.UndefinedBinaryOperatorResult]
if (days [i] >= day_of_year)
~~~~~~~~ ^
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1767
The current use of %Y does not take into account that %Y will
not pad the year with 0's, meanwhile ISO8601 does expect a full
YYYY format for all dates. This breaks the formatting with dates
prior to the year 1000.
Split this into %C%y so 2-digit, 0-padded century and year are
printed separately, this gives the expected YYYY format.
Functions (_g_get_time_charset and _g_get_ctype_charset) to get LC_TIME and LC_CTYPE charset
by using nl_langinfo with _NL_TIME_CODESET and CODESET).
Another functions (_g_locale_time_to_utf8 and _g_locale_ctype_to_utf8) which uses thel and format
the input string accordingly.
Add new test cases with mixing UTF8 and non UTF8 LC_TIME along with UTF8
and non UTF8 LC_MESSAGES.
Closed#2055
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
Both are provided by libm, but `isnan()` is provided as a macro, whereas
`isfinite()` is an actual function, and hence libm has to be available
at runtime. That didn’t trivially work on FreeBSD, resulting in this
refactor.
`isfinite(x)` is equivalent to `!isnan(x) && !isinfinite(x)`. The case
of `x` being (negative or positive) infinity is already handled by the
range checks on the next line, so it’s safe to switch to `isnan()` here.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Rather than parsing the seconds in an ISO 8601 date/time using a pair of
floating point numbers (numerator and denominator), use two integers
instead. This avoids issues around floating point precision, and also
makes it easier to check for potential overflow from overlong inputs.
This last point means that the `isfinite()` check can be removed, as it
was covering the case where a NAN was generated, which isn’t now
possible using integer arithmetic.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The fiendish thing about NAN is that it never compares TRUE against
anything, so the limit checks `seconds < 0.0 || seconds >= 60.0` were
never triggering.
oss-fuzz#28473
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
These variables were already (correctly) accessed atomically. The
`volatile` qualifier doesn’t help with that.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #600
Otherwise it could possibly overflow on 32-bit machines if `year` is
high enough, although I don’t think that’s possible because of limits
applied on it by callers. This should shut Coverity up though.
The limits applied by callers could be circumvented by calling (say)
`g_date_time_add_years()` multiple times. That’s a bug, but not one I’m
going to fix today.
Coverity CID: #1159479
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Many locales have no concept of AM/PM notation, and it’s confusing to
them. It’s an Anglo-centric concept which doesn’t belong in the API at
this level — instead, programs should use more generic format specifiers
which leave the details of how to format a date/time to the locale.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #2082
It was possible to pass in (for example) an invalid year to
g_date_time_new_week(), which would be passed on to g_date_time_new(),
which would (correctly) return `NULL` — but then
g_date_time_get_week_number() would try to dereference that.
Includes a test case.
oss-fuzz#17648
Signed-off-by: Philip Withnall <withnall@endlessm.com>
It was possible to pass in (for example) an invalid hour to
g_date_time_new_ordinal(), which would be passed on to
g_date_time_new(), which would (correctly) return `NULL` — but then
g_date_time_new_ordinal() would try to dereference that.
Includes some test cases.
oss-fuzz#16103
oss-fuzz#17183
Signed-off-by: Philip Withnall <withnall@endlessm.com>
