in reply to Re: Not able to ParseDate lines from a file
in thread Not able to ParseDate lines from a file

The code which I had uploaded was not right. That was a code which I was testing. I have made the changes. Kindly advice. Thanks
  • Comment on Re^2: Not able to ParseDate lines from a file

Replies are listed 'Best First'.
Re^3: Not able to ParseDate lines from a file
by roboticus (Chancellor) on Feb 03, 2012 at 10:48 UTC

    xpl0it:

    Well you still need to check what you're passing in. The error message is quite clearly stating that you're not passing in a valid value for year, so either run your script in debug mode or add some print statements to display values of various variables so you can see what's going on. (For simple quick & dirty stuff, I generally add a print or two, but for tougher problems, I use debug mode.)

    You really ought to familiarize yourself with the debugger, so I suggest trying it out. Run your script like perl -d scriptname.pl and read up on perldebug and have some fun.

    ...roboticus

    When your only tool is a hammer, all problems look like your thumb.

      Yeah! I did that. I put in a few print statements to see what is being printed. So when I execute "print $year", it gives me the desired result, but if the same I put it in the DateTime->new, it gives an error. I read on the DateTime and found that it is expecting an int value. I tried converting the $year to an int, using the int function ... int($year) ... but that made $year to 0. Strange! I read the manuals and did a lot of trials and errors, then since none worked, I thought of putting it up here
        Your code seems to expect eight digits:
        my $year = substr $array[13], 22, 8;
        I don't know which year in the future you post from. It's great that at least eight thousand years into the future, People are still using Perl 5. If you're communicating with people below the 10K limit, they expect years to be four digits. Maybe you should show your input data. Most likely, if you are in fact dealing with four-digit years, you extract leading spaces. Perl will treat a string with leading spaces as 0 in numerical context.

        "it gives me the desired result". Could you be more specific. What was the value of $year. Note that perl does automatic conversion between string and integer value. There is no need for the int() function. If it really is a number you can use it as a number

        Do you still get the error about "undef". In that case you should use something like this to test your script:

        use Data::Dumper; $Data::Dumper::Useqq=1; print Dumper($year);

        This will print out $year as if you had written it in your script as a constant value. If anything strange is happening, for example your $year is a reference or has unprintable control characters in it, this will show it.

        PS: int(undef) will be 0, so whatever you are seeing is expected if $year is really undef. You may have a typo in the variable name (which should give an error if you have "use strict" on)

        xpl0it:

        So what problem are you having? You're not giving complete information, so all I can do is guess. But now you know that the year is incorrect, so that should give you a start.

        You should play around and figure out how scalars work in perl. If you take a string and treat it like a number, it will automatically convert to a number. The int function simply chops off the fractional chunk of a number. Consider:

        Roboticus@Roboticus-PC ~ $ cat foo.pl #!/usr/bin/perl use strict; use warnings; for my $str ('AD 1650', '16.50', '1650') { my $num = $str + 0; # Convert to a number my $int = int($num); # Convert to an int print "string=$str, number=$num, integer=$int.\n"; } Roboticus@Roboticus-PC ~ $ perl foo.pl Argument "AD 1650" isn't numeric in addition (+) at foo.pl line 6. string=AD 1650, number=0, integer=0. string=16.50, number=16.5, integer=16. string=1650, number=1650, integer=1650.

        I don't know if I told you too much or too little, as you don't give enough context about your problem to be certain.

        ...roboticus

        When your only tool is a hammer, all problems look like your thumb.