Possible Time & DateTime RCR: reconciling and extending their apis

ruby-talk
1

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

2

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

3

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

4

If this is so, I can’t help but mention my MutableTime class, the
documentation and source code for which may be found at:
http://phrogz.net/RubyLibs/

···

On Apr 21, 2004, at 8:34 AM, Tadayoshi Funaba wrote:

I think you want a mutable version of DateTime.