CPANday 2017 is over.
This year I remembered CPANday, after a tweet from @neilbowers pointing to a blog post on CPANday 2017, I even jotted it into my calendar all in due time and promised myself I would contribute something.
As CPANday came closer I still had no plans on what to contribute or what to work on. At the same time my workload at work was immense, having CPANday clashing with a sprint ending and a project deadline.
After a whole day of refactoring a test suite for a service/application, I came home late and was about to give up on the idea of contributing anything at all. I had some candidates, but I was too tired to take on something big or overly complex (or so I thought). I considered what could be low hanging fruit and decided to take a look at my Github issues, to see if anything stood out.
An issue with one of the dependencies I use looked interesting, but still perhaps, not something I could do anything about – I guess my weariness, got the better of me and I just dug in.
The issue was related to my CPAN distribution Date::Holidays and problems building Date::Holidays::CN. Date::Holidays::CN depends on DateTime::Astro, which seemed to be the culprit, I took a look at the issue list for DateTime::Astro and located two RTs:
Completely fired up by this quick fix I decided to take a look at the remaining issue.
This required some more debugging, but luckily the issue reporter had given a good hint on how to demonstrate the error using Time::Fake.
$ env PERL5OPT=-MTime::Fake=$(date --date="2016-08-31 12:00:00" +%s) \ prove -b t/006_solar_longitude.t
I had some problems with the date command running on MacOS and I was too tired to get my head around the man page. In order to mimic the example from the issue report.
So I made my own example, calculating the number of days until the end of the month (15 on CPANday).
$ env PERL5OPT=-MTime::Fake=+15d prove --lib -b \ t/006_solar_longitude.t
When I was able to reproduce the error, I did some debugging and found out that the construction of a DateTime object failed, due to the fact that the date parameters were illegal (well the error output actually stated this).
After some thinking and useless experimentation it struck me that the construction was sequential, so I reordered the parameters so the day would be before the month, so we would not be altering the default object (based on the current day) so it could be a invalid date. This resulted in my second PR.
All in all a good CPAN day, short, but effective. My PRs got accepted and a new release of DateTime::Astro is now available on CPAN.
I never thought I would be able to contribute anything, so I was quite impressed with myself and my accomplishments. I even picked up a few new tricks, like Time::Fake.
I still have no idea why DateTime::Astro is needed, but it does not really matter, since the issues were a SMOP.
Now I am just looking forward to CPANday 2018.