From: Sam Roberts Date: 2004-04-18T05:11:39+09:00 Subject: Re: possible Time & DateTime RCR: reconciling and extending their apis 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