Dave Rolsky wrote:
>The use of Date::ISO8601, Date::JD, and Time::Unix seems a bit odd.
>Can't you use DateTime to do all this stuff and avoid the additional
>prereqs?
Using DateTime would gain minimal convenience. On the downside, it's a
heavy module load (both in memory and startup time) and a big dep tree.
It's nearly even a circular dep: it requires DT:TZ, so stuff under DT:TZ
had best not require DateTime. The prospective App::olson isn't actually
a dep of (any version of) DT:TZ, but is closely allied with DT:TZ:Olson.
Date::ISO8601 and Date::JD are already used by DT:TZ:Tzfile and
DT:TZ:SystemV. Date::ISO8601 is light, and certainly pulls its weight.
Date::JD is a bit heavy for what it achieves, due to eager generation
of hundreds of subs; it should probably be autoloading. I wouldn't
mind replacing the minimal use of Date::JD in DT:TZ:{Tzfile,SystemV}
and App::olson with a literal constant. Time::Unix is surprisingly large
for what it does, but still small overall, and unproblematic as a dep.
> We can safely assume that anyone installing
>DateTime::TimeZone has DateTime, I think.
Has it available, sure, but better not to force its use, because of the
heaviness and (in many applications) abstraction inversion of doing so.
For what it's worth, I use DT:TZ in handful of places, but I usually
use it with cheap fake DateTime objects, as seen in the test suites for
DT:TZ:{Tzfile,SystemV}. I've never needed DateTime's arithmetic or other
facilities; I only need a DateTime-alike as a container for RD values to
query timezone objects. In fact, the one place where I do use DateTime
is only using it that way, predates me developing the cheaper substitute,
and will be switched when I get round to it.
So I'm inclined to keep DT:TZ and allied code free of any real dependency
on DateTime.
-zefram
