in reply to Re: time::local
in thread time::local

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";
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!