in reply to time::local

Only the first call using a date in September 2004 is returned correctly. All other bad returns are for different dates within the same year and month.

I cannot reproduce your error, but I can understand what could be going on.

You see, Time::Local tries to approach the epoch time in a particular month by a first guess, estimating how far off it is, and then guessing again... until it finds a time in the desired month. From the start till the end of that month, at least for gmtime, it's just a matter of multiplying the number of days, hours, minutes, seconds since the start of the month, with the appropriate factors, and adding them up, and add them to the value found for the start of the month. For localtime there's a chance it's off by an hour, due to summertime (AKA daylight savings time).

Anyway, once it calculated one time in that month, it caches that result, so it doesn't have to calculate it again for the next date in the same month.

Now if the first calculation for this particular is correct, but the next are off, it's clear to me that the caching system doesn't work as it ought to. It appears to cache a wrong value.

What version of Time::Local do you have? I recall some older version trying to store some values in a byte, though the value it tried to store was too big to fit in a byte. I'm guessing something like this is what's happening in your case. Upgrading Time::Local to a recent version should, hopefully, fix it.

Replies are listed 'Best First'.
Re^2: time::local
by Anonymous Monk on May 09, 2005 at 18:44 UTC
    Time::Local version is 1.07

    Here is the code as running:

    #get seconds for login time supplied
print "values sent to time local 1:1:1:$pday:$pmon:$pyear";    
use Time::Local; 
$pepoch=timelocal(1,1,1,$pday,$pmon,$pyear);
print " return value is $pepoch\n";

    [download]
    Here is an example of the results...
    First the good call for Sept with 2 surrounding data lines:
    values sent to time local 1:1:1:01:0:100 return value is 946706461
    values sent to time local 1:1:1:30:8:104 return value is 1096520461
    values sent to time local 1:1:1:05:4:105 return value is 1115269261
    Next the first bad call with surrounding data:
    values sent to time local 1:1:1:05:6:101 return value is 994309261
    values sent to time local 1:1:1:02:8:104 return value is 194461
    values sent to time local 1:1:1:14:2:102 return value is 1016085661
    Lastly, here is a section of bad dates that fall next to each other:
    values sent to time local 1:1:1:07:3:105 return value is 1112850061
    values sent to time local 1:1:1:26:7:104 return value is 1093496461
    values sent to time local 1:1:1:02:8:104 return value is 194461
    values sent to time local 1:1:1:16:8:104 return value is 1404061
    values sent to time local 1:1:1:16:8:104 return value is 1404061
    values sent to time local 1:1:1:16:8:104 return value is 1404061
    values sent to time local 1:1:1:16:8:104 return value is 1404061
    values sent to time local 1:1:1:05:4:105 return value is 1115269261
    values sent to time local 1:1:1:23:8:104 return value is 2008861
    values sent to time local 1:1:1:05:4:105 return value is 1115269261
    values sent to time local 1:1:1:09:11:104 return value is 1102572061
    The caching issue sounds like a possibility. I think earlier I had one test that I was able to remove all errors by moving the bad data up earlier in the data file. The the question becomes how would I track what is causing the cache error. I think the Time::Local version I have is the most current supported for HP/UX. The other issue is that over 1000 other calls come back correct.

    One of the replies suggested I not use 1,1,1 due to DST. I am using 1,1,1 because I require age in number of days. This still could be a possibility, but the error is for the month of September and the DST change takes place in October. I will still try a run with 4:00 AM to to test that issue.
    Thanks for the help.
    mike
    P.S. Sorry for lack of tags on first post!

[reply]
[d/l]

In Section Seekers of Perl Wisdom