Announcing Date-ManipX-Almanac
One of the remarkable things about the Date-Manip package is its flexibility in the matter of input. If I mean "tomorrow noon," I do not have to think of what today is, I simply specify "tomorrow noon," or its equivalent in any of sixteen other languages.
One day, I thought: what about "tomorrow sunrise?" And thus was born Date-ManipX-Almanac.
In principal, there can be support for any almanac event from any astronomical body in the Astro::Coord::ECI ecosystem. In practice at least most of them are covered, though I have not audited for 100% coverage. This includes the bodies in the Astro-Coord-ECI-VSOP87D distribution, should you want planets through Neptune. Pluto was not covered by the VSOP models -- its exclusion is not a political statement, at least not by me. Satellites are not supported, and currently there are no plans for them.
This package is sort of a shotgun marriage of Date-Manip with Astro::Coord::ECI and friends. As such, the interface may not be completely stable, though I will try to keep it so. There are no encapsulation violations, but there are a couple things I consider warts, and will change if I see my way clear to do so:
- Most of the almanac computations require a knowledge of the position of the user. Ideally this module would tie into the host system's location services or equivalent. But until someone comes up with a Perl module to do this, it will have to be configured.
- This module has its own configuration file, accessed via
configuration item
AlmanacConfigFile
. The prototype tied intoConfigFile
very neatly, but that implementation was rejected because of the encapsulation violation necessary to access the almanac-specific configuration. - The cleaner relationship of
Date::ManipX::Almanac::Date
toDate::Manip::Date
turned out to be has-a, not is-a. Because both objects need to know the language, it is possible in some cases to get them in an inconsistent state by setting a language that is implemented byDate-Manip
but not by this package. This is actually a consequence of the previous wart.
At the moment, the only supported language is English. The GitHub repository contains an implementation of Spanish by me. I did this to try to ensure the possibility of alternate languages, but I am reluctant to release it without someone more fluent than I am proof-reading my extremely rusty Castilian, fortified by the Collins dictionary.
This module requires Perl 5.10 or above, because of the need for
named captures to implement the parse. The DM6
functional
interface is not supported, though it may be possible to do this at some
point. The entire DM6
object-oriented interface is
supported, mostly by delegating to the contained
Date::Manip::Date
object. In fact, this package actually
passes the Date-Manip
test suite, after applying the
obvious patches. Those curious about my notion of obvious should consult
tools/convert-to-almanac
in the
Date-ManipX-Almanac
distribution.
Nice timing, Tom. I just built a little program last week for processing Northern Lights forecasts that relies on the observer's Lat/Lon and time of day. It uses sunrise and sunset values from the MET Norway Weather API since there's no reason to look (or process data) for Northern Lights during the daytime. I still had a few changes I wanted to make to my code, so Date-ManipX-Almanac ought to be a better route for me.
Well, right now it's a development release, and there are a bunch of CPAN testers failures. The two I have spot-checked are from a credible tester, and appear to be giving a day earlier than is expected. I'm guessing a time zone bug of some sort in my code.