1. 04 Dec, 2018 2 commits
  2. 29 Nov, 2018 1 commit
  3. 01 Nov, 2018 1 commit
    • Philip Withnall's avatar
      Revert "gdatetime: Enable compile time check of g_date_time_format() format" · 664fb630
      Philip Withnall authored
      This reverts commits:
       • 9ddcc795ae02adc3
      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
  4. 31 Oct, 2018 2 commits
  5. 31 Jul, 2018 1 commit
  6. 17 Jul, 2018 1 commit
  7. 09 Jul, 2018 1 commit
  8. 01 May, 2018 1 commit
    • Ting-Wei Lan's avatar
      tests: Fix GDateTime format tests on non-English locales · a0c7f854
      Ting-Wei Lan authored
      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.
  9. 13 Apr, 2018 1 commit
  10. 12 Apr, 2018 1 commit
    • Philip Withnall's avatar
      gtimezone: Add g_time_zone_get_identifier() accessor · 89452277
      Philip Withnall authored
      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's avatarPhilip Withnall <withnall@endlessm.com>
  11. 13 Mar, 2018 2 commits
  12. 12 Mar, 2018 2 commits
  13. 20 Feb, 2018 1 commit
  14. 16 Feb, 2018 1 commit
  15. 13 Feb, 2018 1 commit
    • Philip Withnall's avatar
      tests: Use a different time for testing UNIX timestamps · 4183cedb
      Philip Withnall authored
      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
      However, it was failing for TZ=America/Lima, and *only* for that
      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:
      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
      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's avatarPhilip Withnall <withnall@endlessm.com>
  16. 28 Nov, 2017 1 commit
  17. 21 Nov, 2017 1 commit
  18. 16 Nov, 2017 1 commit
  19. 03 Nov, 2017 1 commit
  20. 26 Oct, 2017 1 commit
  21. 11 Sep, 2017 1 commit
    • Robert Ancell's avatar
      GDateTime: Support parsing ISO 8601 strings · 491f835c
      Robert Ancell authored
      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.)
  22. 15 Aug, 2017 1 commit
  23. 05 Jul, 2017 1 commit
  24. 21 Jun, 2017 2 commits
  25. 05 May, 2017 1 commit
  26. 15 Mar, 2017 1 commit
  27. 04 Jan, 2017 1 commit
  28. 04 Apr, 2016 1 commit
    • Bastien Nocera's avatar
      tests: Fix compilation errors due to Y2K format problems · 35bd6920
      Bastien Nocera authored
      Newer versions of GCC are particularly verbose in relation to
      formatting errors, use GCC pragmas to disable warnings for this
      gdatetime.c: In function ‘test_strftime’:
      gdatetime.c:1334:3: error: ‘%c’ yields only last 2 digits of year in some locales [-Werror=format-y2k]
         "a%a A%A b%b B%B c%c C%C d%d e%e F%F g%g G%G h%h H%H I%I j%j m%m M%M " \
      gdatetime.c:1334:3: note: in definition of macro ‘TEST_FORMAT’
         "a%a A%A b%b B%B c%c C%C d%d e%e F%F g%g G%G h%h H%H I%I j%j m%m M%M " \
      gdatetime.c:1334:3: error: ‘%g’ yields only last 2 digits of year [-Werror=format-y2k]
         "a%a A%A b%b B%B c%c C%C d%d e%e F%F g%g G%G h%h H%H I%I j%j m%m M%M " \
      gdatetime.c:1334:3: note: in definition of macro ‘TEST_FORMAT’
         "a%a A%A b%b B%B c%c C%C d%d e%e F%F g%g G%G h%h H%H I%I j%j m%m M%M " \
      gdatetime.c:1334:3: error: ‘%x’ yields only last 2 digits of year in some locales [-Werror=format-y2k]
         "a%a A%A b%b B%B c%c C%C d%d e%e F%F g%g G%G h%h H%H I%I j%j m%m M%M " \
      gdatetime.c:1334:3: note: in definition of macro ‘TEST_FORMAT’
         "a%a A%A b%b B%B c%c C%C d%d e%e F%F g%g G%G h%h H%H I%I j%j m%m M%M " \
      gdatetime.c:1334:3: error: ‘%y’ yields only last 2 digits of year [-Werror=format-y2k]
         "a%a A%A b%b B%B c%c C%C d%d e%e F%F g%g G%G h%h H%H I%I j%j m%m M%M " \
      gdatetime.c:1334:3: note: in definition of macro ‘TEST_FORMAT’
         "a%a A%A b%b B%B c%c C%C d%d e%e F%F g%g G%G h%h H%H I%I j%j m%m M%M " \
      Note that the pragma is outside the function as older versions of GCC
      don't support pragma inside functions.
  29. 16 Oct, 2015 1 commit
    • Allison Karlitskaya's avatar
      GDateTime test: fix occasional failures · 419f5713
      Allison Karlitskaya authored
      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
      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 --
      This is based on a similar patch from Iain Lane, but it uses
      g_get_real_time() instead of g_get_current_time().
  30. 11 May, 2015 2 commits
    • Simon McVittie's avatar
      tests: replace most g_print() with g_printerr() · 45dae4b5
      Simon McVittie authored
      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=725981Reviewed-by: Colin Walters's avatarColin Walters <walters@verbum.org>
      Signed-off-by: Simon McVittie's avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
    • Simon McVittie's avatar
      gdatetime test: don't assume that time stands still · 472dee39
      Simon McVittie authored
      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=749080Reviewed-by: Philip Withnall's avatarPhilip Withnall <philip.withnall@collabora.co.uk>
      Signed-off-by: Simon McVittie's avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
  31. 16 Dec, 2013 1 commit
  32. 31 Aug, 2013 1 commit
  33. 17 Aug, 2013 2 commits