After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 638666 - [gstdatetime] GMT offset fails with GDateTime backend
[gstdatetime] GMT offset fails with GDateTime backend
Status: RESOLVED NOTGNOME
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Mac OS
: Normal major
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-01-04 15:17 UTC by Edward Hervey
Modified: 2011-10-29 15:36 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Edward Hervey 2011-01-04 15:17:06 UTC 
When using GDateTime from glib on macosx, gstdatetime fails to handle properly the gmt offset:

Running suite(s): GstDateTime
72%: Checks: 11, Failures: 3, Errors: 0
gst/gstdatetime.c:278:F:general:test_GstDateTime_get_utc_offset:0: 'ts' (0) is not equal to 'tm.tm_gmtoff / 3600.0' (1)
gst/gstdatetime.c:75:F:general:test_GstDateTime_new_from_unix_epoch_local_time:0: 'gst_date_time_get_hour (dt)' (15) is not equal to 'tm.tm_hour' (16)
gst/gstdatetime.c:50:F:general:test_GstDateTime_now:0: 'gst_date_time_get_hour (dt)' (15) is not equal to 'tm.tm_hour' (16)
FAIL: gst/gstdatetime

Looking at the glib docs doesn't show any fixes. I propose to disable the GDateTime backend for GstDateTime for this coming release and make it use our internal version.
Comment 1 Sebastian Dröge (slomo) 2011-01-08 17:18:18 UTC 
Is there a bug against GLib for this already? If not please create one and add it as dependency of this bug
Comment 2 Kaj-Michael Lang 2011-01-13 11:16:33 UTC 
I get the exact same thing on x86_64 Linux.
Running suite(s): GstDateTime
72%: Checks: 11, Failures: 3, Errors: 0
gst/gstdatetime.c:278:F:general:test_GstDateTime_get_utc_offset:0: 'ts' (0) is not equal to 'tm.tm_gmtoff / 3600.0' (2)
gst/gstdatetime.c:75:F:general:test_GstDateTime_new_from_unix_epoch_local_time:0: 'gst_date_time_get_hour (dt)' (10) is not equal to 'tm.tm_hour' (12)
gst/gstdatetime.c:50:F:general:test_GstDateTime_now:0: 'gst_date_time_get_hour (dt)' (10) is not equal to 'tm.tm_hour' (12)
Tested with glib 2.26.1 and 2.27.91

But it does not happen on 32-bit (i386) with otherwise exactly the same versions of userland libs/apps.
Comment 3 Edward Hervey 2011-01-13 11:33:08 UTC 
Kaj-Michael,

What version of gstreamer is that ?
What distro are you running ?
What is your real timezone offset ?
What's the output of 'date' ?
Comment 4 Kaj-Michael Lang 2011-01-13 12:12:20 UTC 
0.10.31 (I've also tried 0.10.31.3)
Distro: my own
Timezone: Europe/Helsinki (GMT+2)
Date: Thu Jan 13 14:10:45 EET 2011
Comment 5 Tim-Philipp Müller 2011-02-03 20:33:22 UTC 
I presume this still happens with 0.10.32?

Maybe you could investigate this a little? e.g.

 $ cd gstreamer-0.10.32/tests/check
 $ GST_CHECKS=test_GstDateTime_now  make gst/gstdatetime.gdb
 (gdb) break test_GstDateTime_now
 (gdb) run
 ...
 (gdb) n
 ....

 and then step through it one-by-one, and print the various structs (struct tm and the date time struct) along the way, to see what happens and what values get returned?
Comment 6 Fabio Durán Verdugo 2011-06-24 19:16:22 UTC 
any news for this report?
Comment 7 Kaj-Michael Lang 2011-09-06 10:59:11 UTC 
An update of /etc/localtime fixed this for me.
Comment 8 Akhil Laddha 2011-10-21 05:41:09 UTC 
closing the bug as per comment#7