in reply to Re^15: Testing Time::Piece on Windows/VC
in thread Testing Time::Piece on Windows/VC

Which is weird because dumpbin shows strftime() being imported from the right place.

Yes - it's being imported from the right place .... therefore we deduce that the timezone is not being set as intended. I added 3 warn() messages to the relevant section of the 02core.t script. It now looks like: 
SKIP: {
    skip "can't register TZ changes in a pseudo-fork", 2 if $is_pseudo
+_fork;
    use POSIX;
    warn "1 POSIX::strftime: ", POSIX::strftime("%Z\n", localtime);
    local $ENV{TZ} = "EST5";
    warn "2 POSIX::strftime: ", POSIX::strftime("%Z\n", localtime);
    Time::Piece::_tzset();  # register the environment change
    warn "3 POSIX::strftime: ", POSIX::strftime("%Z\n", localtime);
    my $lt = localtime;
    cmp_ok(scalar($lt->tzoffset), 'eq', '-18000');
    cmp_ok($lt->strftime("%Z"), 'eq', 'EST');
}

[download]
Using VC 7 and a perl-5.10.0 built by VC 7 everything works fine and the modified script outputs (as desired): 
.
.
ok 37
1 POSIX::strftime: AUS Eastern Daylight Time
2 POSIX::strftime: EST
3 POSIX::strftime: EST
ok 38
ok 39
ok 40
.
.

[download]
But using VC 7 with ActivePerl-5.10.1 (or with ActivePerl-5.10.0), the output becomes: 
.
.
ok 37
1 POSIX::strftime: AUS Eastern Daylight Time
2 POSIX::strftime: AUS Eastern Daylight Time
3 POSIX::strftime: AUS Eastern Daylight Time
ok 38
not ok 39
#   Failed test at t/02core.t line 65.
#          got: ''
#     expected: 'EST'
ok 40
.
.

[download]
Apparently for this test to work with MSVC++ 7.0 on a perl built by MSVC++ 6, the Time::Piece authors need to devise a way of getting the change to $ENV{TZ} reflected in the right place so that their strtftime call can detect it.

Cheers,
Rob

Replies are listed 'Best First'.
Re^17: Testing Time::Piece on Windows/VC
by BrowserUk (Patriarch) on Feb 03, 2010 at 07:49 UTC

    POSIX::strftime is not a good test. It was supplied binary, with Perl, and so will use "the wrong runtime" relative to Time::Piece built as an add on.

    I suspected that there would be cases like this--other TZ-related calls already a part of the CORE--hence my preference that all the affected CRT routines be moved in to the win32 core, and exported and used (universally) from there.

    At the moment, there are a couple of comments in T::P identifying routines that have been C&Pd from elsewhere, with the note that if they are changed here, they must be changed there also. I've seen similar notes in win32*.c/h; and others in various places in the base CORE. The myriad reinterpretations of *alloc() come to mind again.

    To achieve a real fix to these type of problems, that C&P code re-use would need to be eliminated. But that's a big brief, and will be seen as only necessary to work around an MS-induced situation. Even though it is good practice to avoid C&P.

    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.
[reply]

In Section Seekers of Perl Wisdom