Bug #64663 for Date-Manip: Various self test errors on OpenVMS

Mon Jan 10 18:10:18 2011 zinser [...] zinser.no-ip.info - Ticket created

Subject:

Various self test errors on OpenVMS

Hello Sullivan, first of all thanks for Date::Manip. I use an older version in a lot of my scripts and find it very useful. I am currently setting up a couple of new servers and try to get on recent versions, in particular Perl 5.12.2 and Date::Manip 6.20 (and OpenVMS 8.3-1H1 for that matter). A considerable number of the included self tests fail with the following error message: "Not an ARRAY reference at /U4$/ZINSER/PUBLIC/GNU/PERL_MOD_NEW/DATE/MANIP/blib/lib/Date/Manip/Date.pm line 1366 As an example date_calc_date_date_approx.t fails this way. Looking at the code this line seems to be the problem my $special = $$dmb{'data'}{'rx'}{'offset_time'}[0]; My assumption is that this is supposed to be filled in Base.pm _rx_replace('offset_time') Putting a couple of strategic prints in that code path shows that this is called three times before the error occurs and every time the very first test if (! exists $$self{'data'}{'lang'}{$ele}) is true and just an empty hash is put into $$self{'data'}{'rx'}{'offset_time'} . It never makes it into the second part of the routine where the array is created. I am at a loss how to proceed farther from here. Do you have an idea how to fix this or what to look for? I am aware that testing this yourself might be difficult, so I will be happy to perform local testing. Greetings, Martin

Mon Jan 10 18:55:07 2011 zinser [...] zinser.no-ip.info - Correspondence added

From:

zinser [...] zinser.no-ip.info

I know, it is bad style to reply to oneself, but I might have found some additional information. I tried to run one of my old scripts with the new Date::Manip and it failed with Use of uninitialized value $zone in lc at /perl_root/lib/site_perl/Date/Manip/TZ.pm line 490. ERROR: Date::Manip unable to determine Time Zone. Given the fact that the previous error references offset_times a connection to a problem to determine the TZ seems plausible. I am currently trying to make sense of _get_curr_zone in TZ.pm and to figure out where the association of OS and methods is made mentioned in the comment. Greetings, Martin

Wed Jan 12 07:35:07 2011 sbeck [...] cpan.org - Correspondence added

Please email me at sbeck@cpan.org . I tried replying directly to you, but the mail bounced and I realized that the email address in the report wasn't a real one. I want to debug this, but it will be easier with a more direct line of communication. Thanks

Wed Jan 12 07:35:14 2011 The RT System itself - Status changed from 'new' to 'open'

Sat Jan 15 07:16:11 2011 sbeck [...] cpan.org - Correspondence added

I have received the messages you've emailed to me, and I've replied to them, but I keep getting bounces: 451 4.4.1 reply: read error from zinser.no-ip.info. <zinser@zinser.no-ip.info>... Deferred: Connection timed out with zinser.no-ip.info. If you have an alternate email address (gmail or some other) I can send to, that would be great. In the meantime, I'll post the replies here so hopefully you'll see them.

Sat Jan 15 07:21:14 2011 sbeck [...] cpan.org - Correspondence added

Here's the first message I sent yesterday. Show quoted text

> I made a little progress. First of all I upgraded to 6.21, so all > observations/patches etc. are against the current released version. > > Second I've found the problem with no timezone found in the my script I've > mentioned. That was caused by a special (non standard) timezone

setting on the Show quoted text

> server I used, but while I was in that code section in TZ.pm I've

found three Show quoted text

> issues:

With respect to timezones on VMS, I'm interested in getting some additional methods for determining the local timezone there. In Unix, there are several files I can look in (if they exist) for the timezone. Are there any system files in VMS where I can look? If there are, I'd appreciate it if you could send me a copy of those files (feel free to remove any sensitive information of course) so I can include them in Date::Manip. Show quoted text

> + There is a general problem with the gmtoff method. This is not

limited to Show quoted text

> OpenVMS, if gmtoff is actually called it will also fail e.g. on Linux (the > attached example was created on Linux). The attached gmtoff.patch

demonstrates Show quoted text

> the problem. It disables all other methods for Unix to force the use

of gmtoff Show quoted text

> and adds a few prints to show how the problem happens. Essentially it

seems Show quoted text

> the second _delta_convert('offset',...) does not work ($off is undefined > afterwards). gmtoff.txt shows example output. I hope this kind of narrows > down this problem.

Bug! It's squashed. The gmtoff method will work in 6.22. Thanks Show quoted text

> + As far as the OpenVMS specific methods are concerned. The environment > variable SYS$TIMEZONE_RULE actually contains what it says ;-), i.e. a full > rule how and when to switch from standard to DST. As such it will

never match Show quoted text

> any of the standard names like MET or CST. But it does contain this

name at Show quoted text

> the start of the string. tz_rule.patch contains a one line patch against > TZ.pm that adds a substituion doing "the right thing" similar to the

openUNIX Show quoted text

> case. To protect the innocent it is conditional on the OS being VMS. > SYS$TIMEZONE_DIFFERENTIAL contains the difference between UTC and

local time Show quoted text

> in seconds (e.g. the same value the calculations in gmtoff start off

with). Show quoted text

> Not sure if it would be possible to move the calculation into the foreach > @zone loop, check for a 4 to 5 digit number (with optional sign) and then > perform the corrected calculation for gmtoff there? >

Could you send me the actual value of SYS$TIMEZONE_RULE so that I can make sure to include it correctly? I want to make sure I'm treating it correctly. I'm in the process of fixing the problem with SYS$TIMEZONE_DIFFERENTIAL. It'll be corrected in 6.22 as well.

Sat Jan 15 07:21:57 2011 sbeck [...] cpan.org - Correspondence added

Okay, I've got the changes from the previous email (SYS$TIMEZONE_DIFFERENTIAL and gmtoff both work correctly) working. I've put a copy here: http://sullybeck.com/Date-Manip-6.22.tar.gz You should probably download it and start from there. Note that it does NOT include the changes I suggest below. Show quoted text

> Hello Sullivan, > > now dug down to the original problem in 6.21 again. > > I still return to _rx_replace in Base.pm. This seems to be the place

where Show quoted text

> the array $$self{'data'}{'rx'}{'offset_time'} is actually filled. > > By adding some prints and stepping with the debugger through my test

script I Show quoted text

> see that _rx_replace('offset_time') is now called twice (before three

times) Show quoted text

> and that during use Date::Manip i.e. while the module loads not later

while I Show quoted text

> try to use the functions. > > Now looking again into the function, both times

$$self{'data'}{'lang'}{$ele} Show quoted text

> does not exist for 'offset_time' and is not defined in the code section > depending on this test. I think I might have a problem with language > detection/initialization here. > > Can you give me a hint how to check this in the code? > > Greetings, Martin

There's a couple of things... If the machine you're working on is one where you could comfortably give me temporary access, I'll be happy to log on and debug this directly. If that's not the case, let's try this... Modify your Base.pm as follows: ======= Add the following near the top: use Carp qw(cluck); use Data::Dumper; Then, make the _rx_replace function start with: sub _rx_replace { my($self,$ele) = @_; cluck '#' x 40 . "\n_rx_replace...\n"; print "\n"; print Dumper $$self{'data'}{'lang'}{$ele}; if (! exists $$self{'data'}{'lang'}{$ele}) { $$self{'data'}{'rx'}{$ele} = []; return; } ========= Run a simple script (which fails) and send me the output. I agree that there appears to be some sort of language related problem because ALL of the languages have an offset_time defined (i.e. 'now') so you should never run into the problem you describe.

Mon Jan 24 14:23:48 2011 sbeck [...] cpan.org - Correspondence added

The YAML::Syck module wasn't loading. The next release will test for this and die if it can't be loaded.

Mon Jan 24 14:23:49 2011 sbeck [...] cpan.org - Status changed from 'open' to 'resolved'