Re: possible Time & DateTime RCR: reconciling and extending their apis

> I see no difference in concept, only a difference in construction.

Ruby's Time as a wrapper of the time facilities in C.  It's not only a
technique of implementation.  It's an aim.  Both Date and DateTime are
free from such a thing.

Time provides the system time.  Time::now is the wall clock of the
system.  It appears in places on systems.  For example, file-systems,
logs, clocks, etc.

Today, many systems do not count leap seconds.  But, some systems do
count it.  Many systems have timezone database (e.g. based on tzfile(5)).
But, I don't think they are absolutely right.  They don't share a scale.

But, ruby should have the same scale on the each system, or ruby would
lose consistency on the each system.

Time depends localtime(3)'s interpretation.  It's nearly only one
realistic way today.

> There is question - what is time?
> 
> What I would say is that date is "yyyy-mm-dd", and that time is
> "hh:mm:ss".

I think you want a mutable version of DateTime.

> Only one problem... DateTime doesn't know the local timezone rules...
> and struct tm and its APIs do. Time is hard, it is hard in C, too, and
> not dealt with very well.
> 
> This would be hard to fix, and maybe impossible.
> 
> I don't ask the impossible, I ask that Time and DateTime objects be
> duck-type the same, as much as possible.

I admit your proposal is good at compatibility with Time.  But it is
not so good for both Date and DateTime at all.  Both Date and DateTime
would lose simplicity and consistency.

Time's API is not so bad, as a wrapper.  But, it's not suitable for
Date and DateTime.  Time is so straight as a wrapper.

However, DateTime objects already have minunum compatibility with Time
objects.  What should we do more?

It's easy, if compatibility with Time is the most important for
DateTime.  I think we should redesign the classes if so.

> For the future, maybe I will try to make a DateTime2 that understands
> timezones, but that will be hard, but useful for iCalendar, because
> iCalendar states all dates and times as being in a timezone, and
> contains the definition of that timezone.
> 
> Also, right now, I can wrap DateTime in a Time2 class, that uses
> DateTime as the internal implementation, but has the same API as Time.

I'm looking forward to your fruits.

Thanks,
--tadf