GNOME Bugzilla – Bug 676935
gstdatetime: Unit test fails in Windows
Last modified: 2012-10-22 10:19:18 UTC
Unit test doesn't compile in Windows / mingw-w64: gst/gstdatetime.c: In function ‘test_GstDateTime_get_utc_offset’: gst/gstdatetime.c:280:39: error: ‘struct tm’ has no member named ‘tm_gmtoff’ After disabling tm_gmtoff check the test compiles, but fails with: Running suite(s): GstDateTime 81%: Checks: 11, Failures: 2, Errors: 0 gst/gstdatetime.c:77:F:general:test_GstDateTime_new_from_unix_epoch_local_time:0: 'gst_date_time_get_hour (dt)' (19) is not equal to 'tm.tm_hour' (22) gst/gstdatetime.c:52:F:general:test_GstDateTime_now:0: 'gst_date_time_get_hour (dt)' (19) is not equal to 'tm.tm_hour' (22) Local time is 22:xx and GMT is 19:xx, so apparently GMT offset doesn't work in Windows.
Created attachment 215104 [details] [review] Fix compiling the unit test
Hrm, tempted to just bump the glib requirement to 2.26 for core and remove all our homegrown datetime stuff (instead using the GDateTime wrapper).
Comment on attachment 215104 [details] [review] Fix compiling the unit test I've pushed this with some minor changes: commit 40e68e77600ffddaf909894bea238d63fe505e4e Author: Raimo Järvi <raimo.jarvi@gmail.com> Date: Sun May 27 23:09:43 2012 +0300 tests: fix build of datetime unit test in Windows Also include config.h for all the #ifdef HAVE_XYZ. https://bugzilla.gnome.org/show_bug.cgi?id=676935
As for the test failure, I think I'll just WONTFIX this, since my understanding is that it only happens with the 'home-grown' GstDateTime that is used if building against a GLib < 2.26, and that if it still happens with a GLib >= 2.26 that's a bug in GLib. Please correct me if this is not the case. I would prefer not to bump the GLib requirement just for this. Does it work fine in git master?
(In reply to comment #4) > As for the test failure, I think I'll just WONTFIX this, since my understanding > is that it only happens with the 'home-grown' GstDateTime that is used if > building against a GLib < 2.26, and that if it still happens with a GLib >= > 2.26 that's a bug in GLib. Please correct me if this is not the case. I'm using GLib 2.32.3, so I guess it's a bug in GLib. > Does it work fine in git master? I'm not sure what you mean. Do you mean testing with GLib git master?
I meant if it works with GStreamer core git master branch - I guess I was wrongly assuming you were working with the 0.10 branch. But if you are using glib 2.32 it shouldn't make a difference, it should be pretty much the same in master then. So then the question is: is the unit test buggy, or is it a bug in GLib's GDateTime?
I've been running the tests in GStreamer git master, I haven't tried 0.10. Taking a quick look at e.g. g_time_zone_new and g_time_zone_new_local, they don't look like they would work in Windows: http://git.gnome.org/browse/glib/tree/glib/gtimezone.c (Assuming this code is used in Windows)
I think this is a duplicate of bug #683998, please re-open if not :) *** This bug has been marked as a duplicate of bug 683998 ***