Hello,

I am thinking about Class::Date 2.0 for a long time ago and now I have
some time to write them down. Please comment them if you have time for
this. The goal of the module is still providing a standard datetime type for
perl.

I would like to make 2.0 capable of every possible date and time
calculation and I would like to use existing modules as backends.

Please comment the following document:

Design plan for Class::Date 2.0
===============================

Class::Date 1.0.x state:
- Good:
    - Portable
    - Easy to use
    - Can really be used as a type
    - Almost full-featured
    - Can be used without a C compiler
- Bad:
    - Slow
    - Does not support dates before UNIX epoch
    - Missing features: Business days, Timezones
    - Cannot use existing date modules

Class::Date 2 is a complete rewrite of Class::Date 1.x, which address the
problems of the Class::Date 1.

Planned main features:
- Pluggable adapters for each existing perl modules (e.g. Date::Calc)
- Business day calculation
- The existing interface is kept
- Speed up the existing modules

Planned default adapters in the distribution:
- POSIX date calculation 
    -localtime, gmtime
    - can be used without a C compiler
    - slow
    - Can not handle dates before 1970
- POSIX strftime
- Time::Local (timelocal, timegm)
    - Part of the perl distribution
    - Implemented in perl
- Date::Calc
    - (One of the) fastest date manipulation module
    - Requires C compiler
- Date::Parse
    - Portable date parser module
- Time::Zone (?) 

Classes provided by Class::Date 2:
- Class::Date
- Class::Date::Rel
- Class::Date::Invalid
- Class::Date::Rel::Invalid (?, maybe, see Note 1)
- Class::Date::Adapter::*

Class::Date
-----------
The internal structure of the Class::Date object is kept (array ref), but
"undef" fields can be used to show that the fields is "not calculated". It can
speed up date calculation if we don't use every field (for example "epoch"
field is calculated by Date::Calc backend on demand, because these these are
not required for calculations).

Class::Date::Rel
----------------
"Business days" field added. (TODO: find out a good syntax for it)

Class::Date::Invalid
--------------------
Not changed

Class::Date::Adapter::*
-----------------------
These adapters provide some functions, which are exported into the Class::Date
and Class::Date::Rel namespace. These functions must be the subset of the
Adapeter API.

Adapter API:
------------
Scratch. Names, function list is subject to change

Methods to overwrite:
    Class::Date::
    - strftime
    - register_new_from_scalar (you can call this function to register a new
      date parser with a specified priority)
    - calc_date_from_epoch
    - calc_epoch_from_date
    - calc_wday_from_date
    - calc_yday_from_date
    - calc_dst_from_date
    - tzoffset
    - subtract
    - add
    - compare
    - (timezone functions here)

    Class::Date::Rel::
    - register_new_from_scalar
    - add
    - subtract

Timezone support:
-----------------
Currently I don't know how timezone support can be integrated, I know only the
Time::Zone module for this purpose.

Note 1: About Class::Date::Rel::Invalid
---------------------------------------
I am thinking about implementing this class, which could become an illegal
Class::Date::Rel class.

Regards,

dLux
--
   echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlbxq' | dc

Reply via email to