One of the problems with diagnosing Bug #644473 is that there is no special information produced when g_time_zone_new(identifier) is passed a timezone identifier string that cannot be processed: it just appears to return a valid pointer to a GTimeZone object with a tz offset of 0. That means the caller cannot distinguish "valid tz reference to UTC" from "invalid tz reference", which can then easily lead to later mistakes when handling time in the wrong zone (g_date_time_new, etc.) because the tz lookup did not fail.

Common failure modes include Country/City strings that do not have a zoneinfo/ file, zoneinfo file is found but not processable for some reason (the situation in the parent bug), or known-to-be-unhandled valid formats (gtimezone.c:g_time_zone_new has a comment recognizing that these not-yet-implemented cases exist).

A simple start (that does not require altering the existing API) would be for g_time_zone_new to return NULL if looking up the identifier fails. An enhanced way would be via GError, perhaps an alternative _new() method that took a &GError parameter. The new-interface alternative might be preferable to prevent breaking existing glib internal code that doesn't check a passed GTimeZone pointer before trying to read it. For example, passing NULL as the first parameter to g_date_time_new() currently causes a bus error.