Re^15: Testing Time::Piece on Windows/VC

localtime and gmtime are still being imported from msvcr70.dll. Is that what's stuffing things up ?

No. That's what cured the problem with tzoffset(). It means that all the CRT calls used by Time::Piece are now imported from the same version of the CRT, and therefore operate upon the CRT copy of the environment. Previously, those two were being imported from msvcrt.dll, and hence referenced its copy of the environment, while the tzset(), getenv() & putenv() were coming from msvcr70.dll and operating upon its copy.

The failure you're seeing now, is with strftime() & "%Z", which fails to return the timezone name. Which is weird because dumpbin shows strftime() being imported from the right place.

If the module was picking up anything from the wrong runtime, I'd have expected to see it also importing something from mscvrt.dll, but that's not the case.

Comment on Re^15: Testing Time::Piece on Windows/VC

Replies are listed 'Best First'.
Re^16: Testing Time::Piece on Windows/VC by syphilis (Archbishop) on Feb 03, 2010 at 03:46 UTC
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	[reply] [d/l] [select]
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. "I'd rather go naked than blow up my ass"	[reply]