Re: Rollcall summary for late joiners?

[Daniel Yacob]

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

[Daniel Yacob]

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

[Daniel Yacob]

> 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

[Daniel Yacob]

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