Months will be converted to days with factor 30.5 which will sure give more "precise" result
Thought of that as well, but I read this from the DateManip pages: ...it is NOT known how many days form a month. As a result, the part of the delta containing month/year and the part with sec/min/hr/day must be treated separately. For example, ``Mar 31, 12:00:00'' plus a delta of 1month 2days would yield ``May 2 12:00:00''. The year/month is first handled while keeping the same date. Mar 31 plus one month is Apr 31 (but since Apr only has 30 days, it becomes Apr 30). Apr 30 + 2 days is May 2. As a result, in the case where two dates are entered, the resulting delta can take on two different forms... Hmmmm... Edgar -----Oorspronkelijk bericht----- Van: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] Namens Damir Dzeko Verzonden: dinsdag 30 november 2004 16:27 Aan: User questions and discussions about OTRS. Onderwerp: Re: [otrs] DateCalc and Date::Manip Edgar Meij wrote:
Hi Damir,
One quick question... I've been looking at (and working with :) ) your interval_to_seconds sub in conjunction with Date::Manip. One problem arises though. If a ticket is more than a month old, the DateCalc delta returns months as well. They get chunked off however when parsing to minutes. Have you considered this?
Thanks for noticing that - I haven't, mostly due to fact that I've used it for monthly statistics. My data did not contain any tickets that haven't been answered for so long so it never showed up. Although DateCalc function provides various modes of interval calculations mode-0: +0:0:1071:2:3:10:10 -> 647925010 sec mode-1: +20:6:1:4:3:10:10 mode-2: +20:6:0:7:0:0:0 -> 604800 sec (false!) not all of them make sense over such large interval like a month, or 2 years. In my program I used mode-2 (business date calculation). As you noticed, that will give false result for number of seconds in that interval (since only 4 fields of lowest-significance are used). To correct that problem I'll add other fields in calculation. Months will be converted to days with factor 30.5 which will sure give more "precise" result than algorithm currently used. :) Maybe someone will benefit from it, although I would not like to use customer support system which is that responsive. :) Anyway, correctness first. Thanks for the bug report. Kind Regards, D. _______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support oder Consulting für Ihr OTRS System? => http://www.otrs.de/