I get a similar result on CentOS 5.2 with perl 5.8.8 and blead

$ perl -MTime::Piece -e '$t = Time::Piece->localtime; print $t->tzoffs
+et . "\n"'
46800
$ perl -MTime::Piece -e '$t = Time::Piece->localtime; print $t->strfti
+me("%z") . "\n"'
+0000
[download]

The following comment from Piece.xs looks relevant:

/* XXX struct tm on some systems (SunOS4/BSD) contains extra (non POSI
+X)
 * fields for which we don't have Configure support yet:
 *   char *tm_zone;   -- abbreviation of timezone name
 *   long tm_gmtoff;  -- offset from GMT in seconds
 * To workaround core dumps from the uninitialised tm_zone we get the
 * system to give us a reasonable struct to copy.  This fix means that
 * strftime uses the tm_zone and tm_gmtoff values returned by
 * localtime(time()). That should give the desired result most of the
 * time. But probably not always!
 *
 * This is a temporary workaround to be removed once Configure
 * support is added and NETaa14816 is considered in full.
 * It does not address tzname aspects of NETaa14816.
 */
[download]

Update: Changing the sense of the test on HAS_GNULIBC near the top of Piece.xs to be as follows corrects the problem on my system. I note also that this makes the sense the same as in util.c, though the content of the conditional has other differences. I am not at all certain that it is a good thing to make this change, but I will submit a bug report for someone more knowledgeable than me to have a look

#if defined(HAS_GNULIBC)
# ifndef STRUCT_TM_HASZONE
#    define STRUCT_TM_HASZONE
# else
#    define USE_TM_GMTOFF
# endif
#endif
[download]