GNOME Bugzilla – Bug 779799
gdatetime test fails with tzdata 2017a
Last modified: 2017-03-20 09:47:51 UTC
GLib:ERROR:gdatetime.c:652:test_GDateTime_new_full: assertion failed ("BRT" == g_date_time_get_timezone_abbreviation (dt)): ("BRT" == "-03") The tzdata release 2017a seems to have removed the BRT timezone: $ diff <(curl ftp://ftp.iana.org/tz/tzdb-2016j/southamerica) <(curl ftp://ftp.iana.org/tz/tzdb-2017a/southamerica) *snip* # Pernambuco (PE) (except Atlantic islands) Zone America/Recife -2:19:36 - LMT 1914 - -3:00 Brazil BR%sT 1990 Sep 17 - -3:00 - BRT 1999 Sep 30 - -3:00 Brazil BR%sT 2000 Oct 15 - -3:00 - BRT 2001 Sep 13 - -3:00 Brazil BR%sT 2002 Oct 1 - -3:00 - BRT + -3:00 Brazil -03/-02 1990 Sep 17 + -3:00 - -03 1999 Sep 30 + -3:00 Brazil -03/-02 2000 Oct 15 + -3:00 - -03 2001 Sep 13 + -3:00 Brazil -03/-02 2002 Oct 1 + -3:00 - -03 # *snip* glib 2.50.3, tzdata 2017a
ftp://ftp.iana.org/tz/tzdb-2017a/NEWS says that this is a deliberate change: > Switch to numeric time zone abbreviations for South America, as > part of the ongoing project of removing invented abbreviations.
Created attachment 347854 [details] [review] tests/gdatetime: Use a real rather than invented timezone 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. -- I guess we should test a different timezone, preferably one which exists in the world outside of tzdata. Here's one - what do you think? I can't test Windows, but I got the name from https://msdn.microsoft.com/en-us/library/ms912391(v=winembedded.11).aspx so I hope it's right.
Review of attachment 347854 [details] [review]: ::: glib/tests/gdatetime.c @@ +641,2 @@ #endif + dt = g_date_time_new (tz, 2010, 11, 24, 8, 4, 0); Why change the month here?
(In reply to Philip Withnall from comment #3) > Review of attachment 347854 [details] [review] [review]: > > ::: glib/tests/gdatetime.c > @@ +641,2 @@ > #endif > + dt = g_date_time_new (tz, 2010, 11, 24, 8, 4, 0); > > Why change the month here? Just so it's PST and not PDT, because I am more confident that will work on Windows.
Chun-wei Fan, would you mind reviewing this for whether it’s correct and working on Windows?
Hi Philip, This seems right and does indeed work on Windows. p.s. The test on line 963 (TEST_PRINTF ("%Z", "Pacific Standard Time");) does depend on the location/time zone where the program is being run, so I had to change it to "Taipei Standard Time" for it to work, since that is where I am. Might need to look at how to make this timezone-independent on Windows, but this is a different issue. With blessings, and cheers!
Review of attachment 347854 [details] [review]: Looks good to commit then. Thanks for fixing this.
(In reply to Fan, Chun-wei from comment #6) > This seems right and does indeed work on Windows. Great, thanks for testing. > p.s. The test on line 963 (TEST_PRINTF ("%Z", "Pacific Standard Time");) > does depend on the location/time zone where the program is being run, so I > had to change it to "Taipei Standard Time" for it to work, since that is > where I am. Might need to look at how to make this timezone-independent on > Windows, but this is a different issue. There’s a setlocale() call at the top of the function to set the locale to ja_JP.eucjp, which should make it independent of the locale in the environment. I guess that doesn’t work on Windows, and we need a follow-up bug report for that.
Attachment 347854 [details] pushed as ec02a18 - tests/gdatetime: Use a real rather than invented timezone
Can this please also be pulled into the glib-2-50 branch
(In reply to Michael Biebl from comment #10) > Can this please also be pulled into the glib-2-50 branch Looks like this was done as 3abb760e57888e23e2b8371293895d425608416c