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.

There's a new version which uses the crt localtime and gmtime for the tzoffset calculation. Please try it: http://www.sergeant.org/Time-Piece-1.17.test2.tar.gz

I am very pleased to report complete success. Thankyou!

C:\Perl64\packages\Time-Piece-1.17>nmake test

Microsoft (R) Program Maintenance Utility Version 9.00.21022.08
Copyright (C) Microsoft Corporation.  All rights reserved.

        C:\perl64\bin\perl.exe "-MExtUtils::Command::MM" "-e" "test_ha
+rness(0, 'blib\lib', 'blib\arch')" t/*.t
t/01base.t ...... ok
t/02core.t ...... ok
t/03compare.t ... ok
t/04mjd.t ....... ok
t/05overload.t .. ok
t/06subclass.t .. ok
t/07arith.t ..... ok
All tests successful.
Files=7, Tests=156,  1 wallclock secs ( 0.08 usr +  0.06 sys =  0.14 C
+PU)
Result: PASS
[download]

---

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"

Please try it: http://www.sergeant.org/Time-Piece-1.17.test2.tar.gz

Still getting one test failure when I use MSVC++ 7.0 with ActivePerl 5.10.1 (build 1006):

t/01base.t ...... ok
t/02core.t ...... 1/95
#   Failed test at t/02core.t line 61.
#          got: ''
#     expected: 'EST'
# Looks like you failed 1 test of 95.
t/02core.t ...... Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/95 subtests
        (less 5 skipped subtests: 89 okay)
t/03compare.t ... ok
t/04mjd.t ....... ok
t/05overload.t .. ok
t/06subclass.t .. ok
t/07arith.t ..... ok
[download]

Should have time to take a closer look tomorrow.

Cheers,
Rob