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.

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!

Hai,

Please try to ask the question properly. Question not read exactly. Use code tag for the source code mention. Better my suggestion for the date manipulation you may refer the functions in Date::Calc module. You may get easy Idea to solve.

You may see the various functions and examples below the Date::Calc module based on the time and date problems.

This timestamp is for the end of September, not August. Remember that a month value passed into timelocal is zero based (i.e. month 8 is Sept).

Perhaps this is not the problem you are seeing, but I would caution you from using the '1,1,1' value for the time, if you are just trying to generate a "date stamp". During daylight savings time in the US, in the spring time this may be an invalid time since the clock can jump an hour between midnight and 2 (or is it 3?) am, depending on your timezone. On Apr 3 of 2005 for example there is no such thing as 02:30 in my timezone since one second it was 01:59:59 and the next it was 03:00:00. Correspondingly there will be two different timestamps with the "same" time, in the fall. If you really want to calculate a date stamp, I'd suggest you use a time value that is known to be unique for the day (e.g. noon).