I conclude that you're right that this is the result of the disparate CRTs.

In particular, the fact that both CRTs probably have seperate copies of the environment which defeats T::P's attempts to maintain Perl's copy, the CRT copy and the process' copy in a coherent state

If I install T::P 1.16 via PPM into my AS-binary dist, it works fine. Equally, if I build it using a Perl built from AS sources and VC++ v9, it passes all the tests. Despite that the home-built ASPerl also links to both msvcrt.dll & msvcr90.dll!?

I also think it could be 'fixed'.

If the fixups and work arounds to the tz* functions in T::P, were factored back into the win32 perl core, and exported from perl510.dll--and T::P imported them from there--the problem would disappear. (I think :)

There are some extensive comments in Piece.xs about the CRT, the environment (especially $ENV{TZ}) and tzset - specifically:

 * Therefore, we need to retrieve the value of $ENV{TZ} and call CRT
 * putenv() to update the CRT copy of the environment (if it is differ
+ent)
 * whenever we're about to call tzset().
[download]

And the 2 failing tests I get when I "mix runtimes" come from:

SKIP: {
    skip "can't register TZ changes in a pseudo-fork", 2 if $is_pseudo
+_fork;
    local $ENV{TZ} = "EST5";
    Time::Piece::_tzset();  # register the environment change
    my $lt = localtime;
    cmp_ok(scalar($lt->tzoffset), 'eq', '-18000');
    cmp_ok($lt->strftime("%Z"), 'eq', 'EST');
}
[download]

I expect that when Time::Piece is built with a compiler that uses a different runtime, Time::Piece::_tzset() registers the environment change ok, but registers it with the *wrong* runtime (for the purposes of Time::Piece, at least).

Not sure how this could be fixed. With which runtime will Time::Piece::_tzset() register the change ?
With the runtime of the compiler that built perl ? ... or with the runtime of the compiler that built Time::Piece ?
I suspect it must be the latter, and the trick would be to get Time::Piece::_tzset() to register the change with the former. (Or vice-versa :-)

Cheers,
Rob

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.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"I'd rather go naked than blow up my ass"