Re: Rollcall summary for late joiners?
whoops! I joined late and missed the original rollcall. I wrote Convert::Ethiopic::Date (which replaces Convert::Ethiopic::Time). In a nutshell Ethiopic dates use a different calendar system, time is off by 6 hours ("noon" = 6AM, "midnight" = 6PM), and days have some extra attributes to consider. I'm looking forward to having common base classes to derive a rewritten package from. cheers, /Daniel
Date::Ethiopic Announcement
Greetings, After much feature creep, I've finally released this morning a version of Date::Ethiopic. It is derived from Date::ICal but assumes dates passed to the object as args are in the Ethiopic calendar context. A Gregorian context can be set with a "calscale => gregorian" argument and the date args will be converted into the Ethiopic calendar system. The class also has a "toGregorian" method which returns a Date::ICal object with Gregorian dates. There is also a "calscale" method to check the calendar context of the object when it might be unknown. I recommend these two methods for other packages that also work with non-Gregorian systems. They offer a way to normalize a date for additional conversions, for example: my $ethio = new Date::Ethiopic ( $chinese->toGregorian ); Ah.. a new Date::Ethiopic object can be instaniated from a Date::ICal object, I recommend that too. I haven't been able to keep up with the datetime list during the last year and am out of touch with the latest school of thought on time classes for Perl. I anticipate working on the package regularly and would like to follow standards to the extent that they are available. Using the Date::ICal base class was a conscious attempt at just this. "Date::Ethiopic" I've begun to suspect may no longer be the preferred name choice. Please let me know what naming conventions are recommended. thanks, /Daniel
Re: ANNOUNCE: Date-ICal 2.06
> So is the DateTime suite going to be completely dependent on XS code? If > so, I have at least one app that will need to stick with Date::PCalc or > some pure perl solution. I'd like to add some emphasis to the point raised here. The impetus for the Date-Ethiopic package was to provide a pure perl calendar system conversion package. A number of people who tried to use the XS based Convert::Date::Ethiopic module reported that they were unable to do so. Their web hosting service would allow them to upload text files (html, cgi, perl modules, etc) but they had no access to build local binaries. I am looking forward to migrating Date-Ethiopic under DateTime::Calendar, but it presents an unfortunate burden if I also have to maintain a wholely seperate pure perl implementation. cheers, /Daniel
Calsys & Lang Namespaces
Greetings, I was considering the issue of languages and calendar systems and would like to get some input from the group on the matter. Taking DateTime::Calendar::Ethiopic as a specific example, should languages then go under DateTime::Calendar::Ethiopic::Language:: ? Versus possibly DateTime::Language::Calendar::Ethiopic:: ? I favor the first option, but then I also favor Gregorian:: as a name space and no default calendar system being assumed... ;-) Actually, if Gregorian modules and data went under ::Calendar::Gregorian:: and ::Calendar::Gregorian::Language:: the issue goes away I think. But if that is not going to happen, would a DateTime::Calendar::Ethiopic::Language module really be needed or should we rely on DateTime::Language to know the calendar system and do the right thing? thanks, /Daniel