1. 15 Jul, 2019 9 commits
  2. 14 Jul, 2019 2 commits
  3. 13 Jul, 2019 2 commits
  4. 12 Jul, 2019 2 commits
  5. 10 Jul, 2019 7 commits
  6. 09 Jul, 2019 6 commits
  7. 08 Jul, 2019 4 commits
  8. 05 Jul, 2019 8 commits
    • Philip Withnall's avatar
      Merge branch 'bug-787-investigation' into 'master' · 4e538e67
      Philip Withnall authored
      Fix memory error with GDBusConnection in g_test_dbus_down()
      Closes #787
      See merge request GNOME/glib!963
    • Philip Withnall's avatar
      Merge branch 'win32-enhance-gtimezone' into 'master' · 711b4b05
      Philip Withnall authored
      Win32 enhance and fix gtimezone
      Closes #870
      See merge request GNOME/glib!912
    • Chun-wei Fan's avatar
      glib/tests/gdatetime.c: Fix TZ envvar test on Windows · 5d547271
      Chun-wei Fan authored
      Windows does not recognize the "America/Recife" as a valid timezone
      identifier, so setting the TZ envvar to that will result in "UTC" to
      be returned on Windows.
      Instead, set TZ to be the Windows equivilant "SA Eastern Standard
      Time", and see whether that is indeed our identifier when we create the
      GTimeZone using that.
    • Chun-wei Fan's avatar
      gtimezone.c: Fix identifier assignment on Windows · f24444c5
      Chun-wei Fan authored
      On Windows, we may be using the US DST boundaries by using the default
      "Pacific Standard Time" for rules_from_windows_time_zone() in
      rules_from_identifier().  This has the unfortunate side-effect of
      hardcoding the out_identifier to "Pacific Standard Time", which is
      likely not what we want.
      Instead, upon retrieving the items successfully using
      rules_from_windows_time_zone ("Pacific Standard Time", ...), we just
      set the out_identifier to whatever identifier that was passed into
    • Chun-wei Fan's avatar
      Update the gdatetime Test Program for Windows · 5ca4ac16
      Chun-wei Fan authored
      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.
    • Chun-wei Fan's avatar
      glib/gtimezone.c: Use RegLoadMUIStringW() to query Std/Dlt strings · 2e5d3aa9
      Chun-wei Fan authored
      The existing method of using RegQueryValueExW() to query the Std/Dlt
      strings can only retrive the localized versions of those strings, so
      that means they will vary by the language version of Windows.  Instead,
      use RegQueryValueExW() only as a fallback when RegLoadMUIStringW() fails,
      as RegLoadMUIStringW() can query for the Std and Dlt strings in
      whatever language we need by setting the locale stuff programatically on
      the fly.
    • Chun-wei Fan's avatar
      glib/gtimezone.c: Use Unicode versions of Windows Registry API · c868123c
      Chun-wei Fan authored
      We are going to use RegLoadMUIStringW() in the next commit, since there
      is no real RegLoadMUIStringA() function (it exists as a stub only).
      This is done so that we are consistent along the way
      Also fix rule_from_windows_time_zone_info() as we can't just do a strncpy()
      of tzi->StandardName and tzi->DaylightName directly, as they are wchar_t/
      gunichar2 strings, where we must convert to UTF-8 first.
    • Philip Withnall's avatar
      Merge branch 'dboles/gmacros-docs' into 'master' · dc774db6
      Philip Withnall authored
      docs.c: Forward link from g_auto* → G_DEFINE_AUTO*
      See merge request GNOME/glib!971