GNOME Bugzilla – Bug 793319
GDateTime tests fail in America/Lima timezone
Last modified: 2018-02-13 15:58:40 UTC
This is what I have when my timezone America/Lima: $ ./glib/tests/gdatetime /GDateTime/invalid: OK /GDateTime/add_days: OK /GDateTime/add_full: OK /GDateTime/add_hours: OK /GDateTime/add_minutes: OK /GDateTime/add_months: OK /GDateTime/add_seconds: OK /GDateTime/add_weeks: OK /GDateTime/add_years: OK /GDateTime/compare: OK /GDateTime/diff: OK /GDateTime/equal: OK /GDateTime/get_day_of_week: OK /GDateTime/get_day_of_month: OK /GDateTime/get_day_of_year: OK /GDateTime/get_hour: OK /GDateTime/get_microsecond: OK /GDateTime/get_minute: OK /GDateTime/get_month: OK /GDateTime/get_second: OK /GDateTime/get_utc_offset: OK /GDateTime/get_year: OK /GDateTime/hash: OK /GDateTime/new_from_unix: ** GLib:ERROR:gdatetime.c:136:test_GDateTime_new_from_unix: assertion failed (g_date_time_get_hour (dt) == 0): (1 == 0) Aborted (core dumped) Changing TZ environment variable fixes the issue.
I tried this with all timezones, and it’s only America/Lima which is failing: timedatectl list-timezones | while read line; do echo "$line"; TZ="$line" /opt/gnome/build/glib/glib/tests/gdatetime -p /GDateTime/new_from_unix; done I was wondering if the offset was something to do with DST, since Lima doesn’t observe DST — but there are other timezones which succeed which also don’t observe DST.
Created attachment 368184 [details] [review] tests: Use a different time for testing UNIX timestamps 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 variable). However, it was failing for TZ=America/Lima, and *only* for that timezone. 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: https://www.timeanddate.com/time/change/peru/lima?year=1990. 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 01:00: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 <withnall@endlessm.com>
Review of attachment 368184 [details] [review]: Excellent commit message. I learned something
Thanks for the review. Pushed to master. I’ll backport to glib-2-54 as well. Attachment 368184 [details] pushed as 4183ced - tests: Use a different time for testing UNIX timestamps
Pushed to glib-2-54 as 12a7727352bc4cee3d1ef7b46911d2890b62508d.