Eugene van der Pijll wrote: > It's enough for my needs anyway.
Dangerous words. There certainly are users that need greater precision. I recommend Math::BigRat, which you'll have noticed I'm quite a fan of. Bignums mean never having to think how big your floats are. >I don't understand why you say DT does not know about CJDNs. Did you notice that JD refers to Universal Time but CJD is timezone-relative? That's one of the things that Date::JD makes work right. In DateTime this issue gets into the floating timezone, which looks like a right can of worms. I think the floating timezone is trying to make DateTime do too many things in one class. It's schizophrenic. >DT is built around the very similar concept of RDN, rata die. I'm familiar with RD. I found the book too muddled for my liking. Interesting stuff if one can think past the details, though. But the interface to the DateTime class seems to be more concerned with the Gregorian calendar than RD. I don't see a way to construct a DateTime from RD there, just the Gregorian (year, month, day) tuple. Looks like another abstraction inversion to me: what's a specific calendar doing in such a fundamental class? >of DT::Calendars is always done by transforming to RD's and back, How do you convert between two non-Gregorian calendars using DateTime? It looks to me like the way the calendar modules subclass DateTime mean that you can only deal with one non-Gregorian calendar at once. Am I misunderstanding it? > my hobby is genealogy, and I'm already happy if I >get the year right. ;-) Heh. That's tricky enough, for the Middle Ages, with so many competing dates to start the year. -zefram
