Eugene van der Pijll wrote: >But have you looked at the DT::Format::Epoch example in my first mail yet?
Your example of usage made it clearer. I'm not sure what to make of it yet. I need to ponder it some more. There's a basic difference in our approaches to JDs here. You've implemented CJD as a calendar, a way to denote points in time that are abstractly represented by DateTime objects. That's a good thing to do, once you've got DTs. What I did with Date::JD was at an entirely different level: it has no canonical date format at all, and converts between JD flavours as peers. Yours makes more conceptual sense for users of calendar-like modules; Date::JD is intended purely as glue *between* calendar modules. I'm not sure a comparison is appropriate. Anyway, glad to see that DT::F::Epoch can do that. I didn't realise it was that flexible. >If you care about leap seconds, just stay far away from the floating >timezone. I noticed that bit. >The only reason DateTime.pm (the module) seems to be the fundamental >class of DateTime (the project) is the name; it has no central role, >although there are a number of modules (e.g. formatting modules) that >have been written especially for DT.pm, because it is the most commonly >used. Curious. Is there actually any class with a central role of representing dates/times? >Every DT::Calendar module has two required functions: one that returns >the RD and the number of elapsed seconds in the day; and one that >accepts these values and converts them to a new object. What does the object actually represent? -zefram
