looks good, but something fishy is happening

I used the getTime function from that post, and it doesn't work. I stripped it down to something simpler, and I find that I'm getting different output on each run for the same input! Any clue what's wrong here?

sub getTime{
    my ($filetimepointer) = @_;

    my $systemtime = pack("SSSSSSSS",0,0,0,0,0,0,0,0);

    my $FileToSystem = new Win32::API ("kernel32", "FileTimeToSystemTi
+me", ['P','P'] , 'I');
    $FileToSystem->Call($filetimepointer,$systemtime);

    my($year,$month,$wday,$day,$hour,$minute,$second,$msecond) 
                                    = unpack("SSSSSSSS",$systemtime);
    return ($year,$month,$wday,$day,$hour,$minute,$second,$msecond);
}

sub printtime
 {
 my $time= shift;
 my ($year,$month,$wday,$day,$hour,$minute,$second,$msecond)= getTime 
+(time);
 $second += $msecond/1000;
 print "$year-$month-$day $hour:$minute:$second\n";
 }
[download]

my sample data is (in hex) f0 25 f6 89 15 13 c2 01. I read that from a file, and note that the same 8 bytes are in my unpacked $time variable that I pass into printtime as I see in the file.

Comment on looks good, but something fishy is happening Select or Download Code

Replies are listed 'Best First'.
Re: looks good, but something fishy is happening by jsprat (Curate) on Aug 05, 2002 at 21:26 UTC
`my ($year,$month,$wday,$day,$hour,$minute,$second,$msecond)= getTime (time);` The parameter to getTime should be `$time` not `time` (don't you hate typos - I do). This would explain why you get a different "$time" every "time"... Update: BTW, when I run the code with the 64 bit number you are using, I get ~~6413~~ 2002 as the year. `my $ft = pack "LL", 0x89f625f0,0x01c21315; printtime $ft;` [download] gives me `2002-6-13 20:4:34.964`.	[reply] [d/l] [select]
Re: Re: looks good, but something fishy is happening by John M. Dlugosz (Monsignor) on Aug 06, 2002 at 19:51 UTC
That's it! Wow, so much for `use warnings`. Your pack data is scrambled (on a little endian machine anyway). You will get 89 as your first byte, working towards the most-significant part of the first L (the f0), then go to the 01 and work toward the 15. In the int64, the most-significant byte is 01, which is the right range. —John	[reply] [d/l]