Quoteing tadf / rc5.so-net.ne.jp, on Fri, Apr 02, 2004 at 09:01:49AM +0900:
> > 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.

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

Time is constructed by using the C library's date/time handling
functions and it's struct tm.

Date and DateTime is constructed differently. But what
information/concept do they represent?

Time     == yyyy-mm-dd hh:mm:ss

Date     == yyyy-mm-dd

DateTime == yyyy-mm-dd hh:mm:ss

Do you see a similarity between Time and DateTime? To me, they differ
only in API and implementation.

Why use one? Why use the other? Why is there both?

I'm not the only one confused, there was a post last week from somebody
trying to figure out how to represent a time past the resolution of
time_t on their system.

> 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.

Your comments make me reconsider, and I was wrong.

When people create objects, they must know what they create, so having
different constructors is OK.

But, I would like to be able to return an object to a caller of my
library that represents a "yyyy-mm-dd hh:mm:ss", and for them not to
know whether it is a Time or a DateTime when they use it - to be able to
call #strftime, to_int, #mon, #day, #hour, #to_a, etc. I would create a
Time if I could, but a DateTime if I had to.

> > 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.

There is question - what is time?

What I would say is that date is "yyyy-mm-dd", and that time is
"hh:mm:ss".

What time do we have dinner? At 7 PM. But, time exists in a context.  It
is related to date... because not all times exist for all dates
(because of daylight savings time, leap years, leap seconds...).

So, things should be like your library: base class is Date, and DateTime
extends it.

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.

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.

Thank you,
Sam