Hi,

> The situation is a little confusing because the diffences in the APIs
> are reflections of the underlying implementation technique, not of a
> conceptual difference between a Time and a DateTime:

Perhaps, there is difference in concept.

> 1 - that DateTime support all the methods of Time, so that it can be used
> anywhere a Time can, with the the magic of DuckTyping, the only
> difference will be that DateTime has a larger range

I think DateTime is a supplement for Date, not Time.  DateTime can't
replace Time.  Time is basically a wrapper of struct tm, Date is not.
DateTime is basically only a simple extension of Date.

Well, I have no inclination for this so far...

I can't now implement Date::local yet, anyway.  It requires support of
proper timezone (and I don't want to recommend anyone to use it).

Time::new takes no arguments.  Do you also want to change Date::new?
I may admit it if manay users want it.  But it is not small for Date.

> 2 - that using times (both Time and DateTime) be made easier by adding some
> methods to one or both classes

It seems like a container of some date/time elements.  The present
Date is not.  They are quite different.  I'm not sure which is better.

> 3 - that a way of making DateTime aware of daylight savings time be thought up

Time doesn't dump its zone information with Marshal.  Time can't
handle multiple timezone simultaneously.  Time has still restrictions
at support of timezone.

On DateTime, it is more difficult.  DateTime supports more wide span.

Could you contribute good solution and code?  I have no idea yet.
Japan where I live does not have summer time (It's nice).

Thanks,
--tadf