Patch from Andrew Suffield:
> 'TZ=MOO date' gives confusing output; it uses UTC but claims to be
> whatever timezone you told it. If you were expecting the timezone to
> be valid, this output is not correct.
> 
> This is caused by the way that glibc parses $TZ; if the string is
> unrecognised, it interprets it as a name followed by an offset from
> UTC. (The relevant code is tzset_internal() in time/tzset.c)
> 
> The code already checks to see whether there is a valid offset in the
> string or not. Currently it copies the timezone name first; since the
> intent was probably not to change the name if no offset was specified,
> I propose this change:
> 
> [... see patch below ...]
> 
> The old behaviour is still available by using TZ="MOO+0", if it is
> really desirable to change the name of the timezone in this manner.

Index: time/tzset.c
===================================================================
--- time/tzset.c.orig
+++ time/tzset.c
@@ -216,7 +216,7 @@
 
   /* Clear out old state and reset to unnamed UTC.  */
   memset (tz_rules, 0, sizeof tz_rules);
-  tz_rules[0].name = tz_rules[1].name = "";
+  tz_rules[0].name = tz_rules[1].name = "UTC";
 
   /* Get the standard timezone name.  */
   tzbuf = strdupa (tz);
@@ -225,14 +225,14 @@
       (l = strlen (tzbuf)) < 3)
     goto out;
 
-  tz_rules[0].name = __tzstring (tzbuf);
-
   tz += l;
 
   /* Figure out the standard offset from UTC.  */
   if (*tz == '\0' || (*tz != '+' && *tz != '-' && !isdigit (*tz)))
     goto out;
 
+  tz_rules[0].name = __tzstring (tzbuf);
+
   if (*tz == '-' || *tz == '+')
     tz_rules[0].offset = *tz++ == '-' ? 1L : -1L;
   else