I thought it was finally time I discussed DateTime::Tiny.
For anyone that hasn't heard of my ::Tiny series of modules, they are a
set of modules designed to implement a usable subset of the same
functionality of a commonly used and more powerful in "as little code as
possible".
They are intended for use when the functionality you need to implement
is only secondary to the main purpose of the module, and you don't want
a large system.
So far, the list includes
Config::Tiny
CSS::Tiny
YAML::Tiny
Date::Tiny
Time::Tiny
The rules for the Tiny suffix are as follows.
1. The module should be implemented in "as little code as possible"
2. The module should implement a useful subset of functionality
3. The module should use at least 1/10th the amount of memory overhead,
ideally less than 100k
4. The module MUST have no non-core dependencies
5. The module MUST be only one single .pm file
6. The module should be back-compatible to at least 5.004
7. The module should omit functionality rather than implement it
incorrectly.
8. If applicable, the module should be compatible with the larger module.
Now to the date/time modules specifically
On a recent project, I needed to objectify a date, time and datetime
from a communications protocol, carry those dates and times through a
message translation process, and then spit them back out.
The dates were ISO-compatible in one case, and some weird local
date/time format on the other side.
While debugging this I stepped down into the DateTime code I was using
and it occured to me that DateTime objects are relatively heavy and a
fair amount of instructions to parse.
There's also the matter of the memory overhead, which for this project
is a little tight.
Now, having made the stupid mistake of trying to implement a time
library before, I know how stupid it is to even try.
But I realised that I actually only needed a fairly small amount of
functionality. I didn't need to compare the date/time values, or do math
on them. I just had to hold it in memory as a data object, and serialize
it out the other end.
So none of the normal complexity of DateTime was really needed.
So I've implemented Date::Tiny, Time::Tiny and I have locally a copy of
DateTime::Tiny.
What each of these do by default is parse and serialize an ISO date/time
string to an object, and serialize back out to a string.
And that's it. No math or comparison or interesting manipulation
functionality. Just a simple parse and deparse into one ISO format.
They do, however, have a ->DateTime method which (if DateTime is
installed) will load DateTime and return the equivalent DateTime object
for each Tiny object (using the appropriate params for locale/tz etc).
Both Date::Tiny and Time::Tiny come in at 35 lines of code each.
DateTime::Tiny would be maybe half a dozen lines more.
However, DateTime::Tiny imposes on your namespace, so I'd like your
blessing on this.
Alternatively, someone suggest an alternative that complies with the
rules above.
The only suggestion so far was the delayed-inflation class, but as I
understand it that has DateTime as a dependency anyway, so it violates
the Tiny rules.
Adam K
