Hi Graciliano, On Sun, 21 Mar 2004, Graciliano M. P. wrote:
> I have just released the module Date::Object, that in the first view is an > alternative to DateTime, at least for the most common things when handling > dates. It nice to see that the DateTime project has become so well known. :) > http://search.cpan.org/~gmpassos/Date-Object-0.01/ > > The main pourpose is to handle dates using a single object or make multiple > "Date::Object"s work together to calculate and handle dates. > > Other main poupose of Date::Object is to find a simple way to store dates in > a persistent enverioment (any database) using a simple INTEGER field. Did you see C<DateTime::epoch> and C<DateTime::from_epoch> in the DateTime.pm pod? > The use of a INTEGER field for that make possible searches in the DB by > ranges, what is impossible with normal storages of dates, specially if they > are saved as STRING, generally in the comon format of "YYYY-MM-DD". Also an > INTEGER field have all the informations of a date, including year, month, > day, hour, minute, second and timezone. Other good thing is that any DB > supports INTEGER fields, what doesn't make our Perl code dependent of the > SQL nuances of each different way to handle dates of each DB. I don't know of any 'SQL' database that can't search on time ranges. Although, it is true that these functions are generally extensions to ANSI SQL. > Internally Date::Object has a simple architecture and is small compared to > other Date modules, since all is based in the time() (all the seconds from > 1970-1-1) of the object. Soo, each object has it's own time value and > timezone, and from this 2 values any information is calculated. Soo, change > only 2 values make all the work easier to create the module and move the > date through the timeline, and with simple methods is possible to add/remove > days, weeks, months, years, and make comparations. That first statement is incorrect. The behavior of C<time> is platform specific. In your database example above, you'd have to make sure all the platforms accessing the database use the same epoch. For a solution to this problem please see <DateTime::Format::Epoch>. The timezone handling is completely broken. Despite the fact C<isdst> is in the API only offsets from GMT are supported. This means there is _NO_ way to tell if changing timezones also causes a DST change UTC is not supported but in fairness support for it isn't claimed. The data math is also broken in many ways. The algorithm for calculating leap years (year / 4) is incorrect. A lot of mutators show very primitive behavior. If I add 1 month to January 31st what is the date? I've just skimmed through the code so I'm sure I missed errors. Getting date and time handling _correct_ is really, really, really hard. (Insert the standard plug for Dave Rolsky's DateTime.pm here) > As any other author that releases a new module, I'm asking for some feedback > about the module. I'm sorry if this sound harsh but you've created another typical C<Date::*> module. There is a reason why getting DateTime and the related modules _correct_ took (and is taking) so much labor. I don't think many people are cognizant of the complexity that lurks behind seemly simple issues in this domain. I encourage you and anyone else that are considering writing a date and/or time handling module to discuss it on the [EMAIL PROTECTED] mailing list. Cheers, -J --
