Zefram schreef: > >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?
No; perhaps it is most accurate to say that dates/times are represented by the list (RD_days, RD_secs, RD_nanosecs) which is exchanged between modules when converting calendars. Internally, however, DateTime::Calendar modules may store their data in any way they wish. > >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? Depends on the DT::C module. It can be: * A day, expressed as a date in a certain calendar. E.g. my Hijri (islamic) calendar, which doesn't do "time". * A "precise" moment, expressed as a date and a time in a certain calendar, time scale and time zone. E.g. a DateTime object, with time zone UTC. (Whether it represents the exact moment, or a whole second or nanosecond, is debatable). * A "date/time" expression in a certain calendar and time scale. These are floating datetimes, and do not represent a specific moment. Importantly, there are no "calendar-less" datetime objects. One may see this as an important difference between your approach and DateTime's; one may also see it as an implementation detail. Eugene
