[ic] time tag with adjust in February bug?
mike at perusion.com
Mon Apr 1 13:10:14 UTC 2013
Quoting Peter (peter at pajamian.dhs.org):
> On 04/02/2013 01:00 AM, Mike Heins wrote:
> >The only way to do this properly would be to run mktime after
> >each atom of adjustment, generating a new @times array, and then
> >apply the next. Even then, you may not get what you think you
> >are going to get.
> Right, even adjusting just the month you get:
> 31st Mar - 1 month = 31st Feb which gets corrected to 3rd of Mar (or
> 2nd if it's a leap year). Fail already.
> The only way I can think of to do this "correctly" is to use
> DateTime. What I could do is check for the existence of DateTime and
> use that if it's present, and fall back to the existing code
Yes, that makes sense. Originally, I didn't want to deal with months
as a standard function precisely because the behavior of months is
truly undefined. Even the date modules Date::Calc and DateTime, either
of which do a great job, have to have a treatment of it. I felt that
if you wanted to deal with DST or months, you should write your own
code so that you could define it yourself.
We have Date::Calc as a dependency in some code as I recall, and it is
in InterchangeKitchenSink, so it may be wise to use that instead of
Perusion -- Expert Interchange Consulting http://www.perusion.com/
phone +1.765.253.4194 <mike at perusion.com>
I don't want to get to the end of my life and find I have just
lived the length of it. I want to have lived the width of it as
well. -- Diane Ackerman
More information about the interchange-users