Update the gdatetime test program to make use of the updates that was
done in gtimezone.c in the previous commit, so that we don't have to
worry what language version of Windows the tests are being run in, but
instead be assured that we produce and check for the English-language
time zone name strings.
Also, instead of testing for "Pacific Standard Time" in
test_GDAteTime_printf(), use GetDynamicTimeZoneInformation() to get the
actual time zone string (where the system running the test program is)
we want to check for, because on Windows the actual result will be
dependent on which timezone the system running the test program is in.
https://bugzilla.gnome.org/show_bug.cgi?id=719344
This is a follow-up to a0c7f85437093b073b3e3b2c9cb337065b6ea896.
In addition LC_MESSAGES, we should remove LC_ALL from the environment
as well. Otherwise, LC_ALL overrides LC_MESSAGES, causing the test to
fail on FreeBSD when LC_ALL is set to a non-English locale.
In date time formatting routine, instead of converting from UTF-8 to
locale charset and then from locale charset to UTF-8, store all
intermediate result in UTF-8.
This solves the issue where user provided UTF-8 format string might be
unrepresentable in the current locale charset.
Fixes issue #1605.
In glibc, LANGUAGE is used as highest priority guess for category value.
Unset it to avoid interference with tests using setlocale and translation.
Issue #1357.
This reverts commits:
• 9ddcc79502349e02a1e796b363d891e177337af5
• ae02adc3c3795bb32348c07d8f48504b41e9e2c7
g_date_time_format() supports a few non-standard format placeholders:
• %:z
• %::z
• %:::z
These are all gnulib strtime() extensions, and hence are not recognised
by the compiler when the function is annotated with G_GNUC_STRFTIME.
However, this wasn’t noticed when we originally merged this change
because the errors were disabled in the tests which covered those
placeholders.
Formatting code for `%z` specifier incorrectly assumed that sign of
offset from UTC can be recovered from the number of hours alone, which
is not true for offsets between -01:00 and +00:00.
Extract and format sign separately to avoid the problem.
Issue #1337.
When checking that the timezone code falls back to UTC if a zone is
unknown, don’t use ‘PST’, because that can actually exist on some
systems.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1433
These tests will work if the glibc translations are up to date, or if
the GLib translations are installed and up to date; but not if neither
are in place.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
https://gitlab.gnome.org/GNOME/glib/issues/1447
Use either g_get_real_time() or g_date_time_new_now_local(). This means
we don’t need to worry about time_t being 32b in future (the year 2038
problem), and it makes the need for error handling a bit more explicit.
Improve the error handling in several cases.
Based on a patch by Niels De Graef
(https://gitlab.gnome.org/GNOME/glib/merge_requests/142).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1402
It seems that the test expects g_date_time_format to return formatted
results in English, and there is no setlocale (LC_ALL, "") call in the
file so the test does run in the default C locale. However, gettext
seems to read the value of LC_MESSAGES from the environment by itself.
Even if the value of LC_MESSAGES locale is C because of not calling
setlocale, gettext still translates the name of the month according to
the LC_MESSAGES environment variable, causing g_date_time_format_locale
to fail on the "%b" test case because it cannot convert UTF-8 text
returned by get_month_name_with_day to ASCII.
To avoid the test failure, we set the LC_MESSAGES environment variable
to C before format tests and restore it at the end of the function.
https://bugzilla.gnome.org/show_bug.cgi?id=795165
This is a non-trivial accessor which gets the identifier string used to
create the GTimeZone — unless the string passed to g_time_zone_new() was
invalid, in which case the identifier will be `UTC`.
Implementing this required reworking how timezone information was loaded
so that the tz->name is always set at the same time as tz->t_info, so
they are in sync. Previously, the tz->name was unconditionally set to
whatever was passed to g_time_zone_new(), and then not updated if the
tz->t_info was eventually set to the default UTC information.
This includes tests for the new g_time_zone_get_identifier() API, and
for the g_date_time_get_timezone() API added in the previous commit.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795165
This patch relaxes the comparison rules and allow the month names to be
in a mixed case.
Translators should be allowed to provide the month names in a different
case (lower/upper case, not grammatical case) from the content of glibc
because it is disputable at the moment whether the month names should
follow the language rules strictly and be titlecased only if it is
obligatory to titlecase them or they should be also titlecased in the
standalone case. Hopefully in future a conversion specifier will be
invented to control the upper/lower case individually.
https://bugzilla.gnome.org/show_bug.cgi?id=793645
See the previous commit. By convention, GLib assumes strings loaded from
gettext are always in UTF-8, but we do need to tell gettext this. In
most other tests, it doesn’t matter; but in the gdatetime test, we test
re-encoding month names from EUC-JP, so we need to ensure the
translations start in UTF-8 correctly.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793578
Supports %OB (alternative, standalone, nominative) month name along
with the old %B (primary, in a complete date format context, genitive)
month name. Similarly %Ob and %Oh for abbreviated month names.
Depending on the underlying operating system uses nl_langinfo()
or provides our custom implementation.
(Tweaked by Philip Withnall <withnall@endlessm.com> to add test case
comment and bug reference.)
https://bugzilla.gnome.org/show_bug.cgi?id=749206
The test_GDateTime_new_from_unix() test creates a UNIX timestamp
representing 1990-01-01 00:00:00 in the local timezone, and then turns
it into a GDateTime using g_date_time_new_from_unix_local(). This should
succeed regardless of the current local timezone (TZ environment
variable).
However, it was failing for TZ=America/Lima, and *only* for that
timezone.
As it turns out, Lima used to have a DST leap at exactly 00:00:00 on the
1st of January — but this stopped in 1994, which made investigation a
bit harder. See:
https://www.timeanddate.com/time/change/peru/lima?year=1990.
What was happening is that 1990-01-01 00:00:00 was being converted to
the timestamp 631170000, but GDateTime was converting that timestamp to
1990-01-01 01:00:00 when loading it. Both conversions are correct: a DST
leap creates an equivalence between an hour’s worth of timestamps.
We can somewhat validate this by seeing that timestamp 631169999 maps to
1989-12-31 23:59:59, and timestamp 631170001 maps to 1990-01-01
01:00:01.
Fix this by changing the date used by the test to one where no timezone
was undergoing a DST leap in 1990. This should never change, as all that
data is now historical.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793319
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
There are some GDateTime tests which need to be skipped if changing the
locale fails. Use g_test_skip() to do that, rather than just a
human-readable message.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The carbon framework is deprecated and not really related to OSX's
printf features. Directly test compiler-defined token for the platform
itself rather than that autodetected framework as a proxy.
https://bugzilla.gnome.org/show_bug.cgi?id=731625
Where we were already treating GHashTables as sets, modify them to use
the set-specific APIs g_hash_table_add() and g_hash_table_contains(), to
make that usage more obvious and less prone to being broken.
Heavily based on patches by Garrett Regier <garrettregier@gmail.com>.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=749371
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
We can’t reasonably control the local timezone in the test
environment, so drop some assertions which were assuming the local
timezone offset was not big enough to cause an overflow in the GTimeVal
handling for GDateTime.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The addition (highest_success + lowest_failure) could have overflowed,
and typically would do on 32-bit platforms where the real
highest_success should be G_MAXLONG. Fix that, and introduce special
handling of the corner case of (highest_success = G_MAXLONG).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=783841
On architectures where sizeof(glong) == 32 bits, there are no problems
with overflow when constructing a GDateTime from a GTimeVal. Adjust the
test for this by basing it on the maximum supported tv_sec value it can
calculate, rather than a fixed ‘known unsupported’ value.
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
The tzdata maintainers had previously invented abbreviations for
timezones. As of their 2017a release, the one we were testing ("BRT")
has been dropped.
Switch to testing PST, which is a real timezone abbreviation.
https://bugzilla.gnome.org/show_bug.cgi?id=779799
We were using the time() library call to get the current time from the
system in order to compare it to the time returned by
g_date_time_new_now().
Of course, we took care to ensure that the time (in seconds) didn't
change in the middle of this process by checking the before and after
value of the system time.
Unfortunately, the system time as measured by time() was being taken
from a less-accurate clock source than the time used by GDateTime. As a
result, we could have GDateTime already into the next second while the
"seconds" value of the time returned by time() was still in the last
one, even when checked "after".
Avoid the problem by using the same ultimate source for time --
g_get_real_time().
This is based on a similar patch from Iain Lane, but it uses
g_get_real_time() instead of g_get_current_time().
https://bugzilla.gnome.org/show_bug.cgi?id=754994
I searched all files that mention g_test_run, and replaced most
g_print() calls. This avoids interfering with TAP. Exceptions:
* gio/tests/network-monitor: a manual mode that is run by
"./network-monitor --watch" is unaffected
* glib/gtester.c: not a test
* glib/gtestutils.c: not a test
* glib/tests/logging.c: specifically exercising g_print()
* glib/tests/markup-parse.c: a manual mode that is run by
"./markup-parse --cdata-as-text" is unaffected
* glib/tests/testing.c: specifically exercising capture of stdout
in subprocesses
* glib/tests/utils.c: captures a subprocess's stdout
* glib/tests/testglib.c: exercises an assertion failure in g_print()
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=725981
Reviewed-by: Colin Walters <walters@verbum.org>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
If we call time(NULL), then do something (however trivial), then call
g_date_time_new_now_utc(), they do not necessarily share a seconds
value. Let's say the gmtime call takes 2ms. time(NULL) could
return xx:xx:23 when the time is actually xx:xx:23.999999, resulting
in the g_date_time_new_now_utc() happening at xx:xx:24.000001. This is
unlikely, but did happen to me in a parallel build:
GLib:ERROR:.../glib/tests/gdatetime.c:674:test_GDateTime_now_utc: assertion failed (tm.tm_sec == g_date_time_get_second (dt)): (23 == 24)
A similar argument applies to the rollover from xx:23:59.999999 to
xx:24:00, so comparing seconds with a 1s "fuzz" or a >= comparison
is not sufficient; and so on into higher-order fields.
I haven't seen the other tests that use _now() fail in the same way,
but they could.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=749080
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This line was apparently causing build problems on Win64,
and since the only test involving the t_str variable was
already commented out, lets just take this out altogether.
https://bugzilla.gnome.org/show_bug.cgi?id=696970
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
test_GDateTime_diff() checks that the span from 2009-01-01 to
2010-01-01 is exactly 365 * G_TIME_SPAN_DAY, but it does this using
local time, and so fails if you are in a timezone that is in the
southern hemisphere which only did DST during one of 2008-2009 and
2009-2010 (in which case the year will end up being one hour too long
or too short).
Switch the diff tests to use UTC time instead; there are plenty of
other local time tests already.
https://bugzilla.gnome.org/show_bug.cgi?id=701529
