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 into ConfigFile 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 to Date::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 by Date-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.

2 Comments

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.

Leave a comment

About Tom Wyant

user-pic Fine Perl code for over 0.005 centuries.