Yep! I get the same thing. The failing call is the method tzoffset() which calls CORE::localtime() and CORE::gmtime() to calculate the offset, in order to test the effect of Time::Piece::_tzset();.

The problem is that those two core routines--pp_localtime() & pp_gmtime()--are built when perl is built, and so call the CRT routines of the same name from CRT available then.

But Time::Piece::_tzset(); is calling getenv() putenv() and tzset() from the runtime available when T::P is built, which in this scenario is the wrong runtime.

If the method tzoffset() called the CRT localtime() & gmtime() from the CRT directly, rather than via the CORE; or if pp_* wrappers around putenv(), getenv() and tzset() were exported from the CORE; either way, only one copy of the CRT would get used and the problem would disappear.

Or, my preferred option would be to add a win32_tzset() to win32.c to go with the win32_getenv() and win32_putenv() that are already there, and have these used in place of the CRT routines constistently. This would bypass the CRT copy(ies) of the environment completely, and so mirror the rationality that GSAR originally cited back in 1997:

DllExport int
win32_putenv(const char *name)
{
    dTHX;
    char* curitem;
    char* val;
    int relval = -1;

    if (name) {
        Newx(curitem,strlen(name)+1,char);
        strcpy(curitem, name);
        val = strchr(curitem, '=');
        if (val) {
            /* The sane way to deal with the environment.
             * Has these advantages over putenv() & co.:
             *  * enables us to store a truly empty value in the
             *    environment (like in UNIX).
             *  * we don't have to deal with RTL globals, bugs and lea
+ks
             *    (specifically, see http://support.microsoft.com/kb/2
+35601).
             *  * Much faster.
             * Why you may want to use the RTL environment handling
             * (previously enabled by USE_WIN32_RTL_ENV):
             *  * environ[] and RTL functions will not reflect changes
+,
             *    which might be an issue if extensions want to access
             *    the env. via RTL.  This cuts both ways, since RTL wi
+ll
             *    not see changes made by extensions that call the Win
+32
             *    functions directly, either.
             * GSAR 97-06-07
             */
            *val++ = '\0';
            if (SetEnvironmentVariableA(curitem, *val ? val : NULL))
                relval = 0;
        }
        Safefree(curitem);
    }
    return relval;
}
[download]

Of course, one also has to wonder at the MS logic of keeping runtime copies of the environment instead of having the CRT getenv() and putenv() translate directly into GetEnvironmentVariableA() & SetEnvironmentVariableA()? But that's a question that you could never get an answer to even if they didn't make it so hard to ask it.