Joshua Hoblitt wrote: >Is all that stuff just a reinvention of the wheel?
Yes, but this time it's round. > What's the value add >over DateTime and the zillions of other date/time modules already on CPAN? Three things: API isolation; arithmetic-friendly (and calendar-neutral) interface; unlimited range. The Date::ISO8601 module implements those calendars *in isolation*. It's suitable to plug into anything that wants to use those calendars as part of something else. Modules such as DateTime implement these calendars, but that implementation comes along with mandatory processing of time of day and timezone. DateTime offers no object that represents merely an abstract date. Secondly, most calendar-handling modules offer functions that, for example, take a (year, month, day) tuple and a number of days and return a (year, month, day) tuple that identifies the date so many days later. This way of doing date arithmetic is the wrong way round. Date::ISO8601 treats the (year, month, day) tuple as merely a surface encoding of the date, which is what it is, and not as the natural form of the underlying data. Using CJDN, a linear count of days, as the basic format for representing dates lets the user do the arithmetic directly. It also avoids forcing the user to deal with one calendar and its (year, month, day) tuples when ey might only be interested in a different calendar, such as the (year, week, day) calendar from ISO 8601. Finally, my modules allow use of bignums, avoiding range limitations. Several date-handling modules on CPAN actually impose arbitrary limits on the dates they will handle. The ones that don't, apart from mine, break when the dates overflow the native integer format. Additionally, for Date::JD I've never seen a CPAN module with that functionality at all. >I have to admit I haven't really looked at your code in depth but I >don't see how you can accurately be calculating TT/etc. without doing an >interpolation of IERS data. Er, you can't be talking about Date::ISO8601 and Date::JD here. I guess you're talking about my Time::TT and Time::TAI? These do indeed convert between different realisations of TT by interpolating BIPM data. Quite a different subject area from what (it seems) this mailing list is concerned with, but a good example of why one might want to use more than one model of time-of-day with a calendar module. -zefram
