TimeSpan and DateAndTime? Date is a TimeSpan with a duration of 1 day? aka TimeStampTest>>#testAccessing failure

> I haven't been Squeaking much for a while but for some reason I got the
> urge to exercise and break off a little rust so I thought I would look
> at a few failing tests in Trunk and see if I could address one or two.
> I've had a little success (barring personal misunderstanding) with a
> couple in the last two days but I ran into TimeStampTest>>#testAccessing
> and learned about a whole new level of 'not understanding'.
>
> The test itself seems simple enough; compare the date and time parts of
> a prepared TimeStamp value to 'literal' values that should be
> equivalent.  The test fails and weirdly enough because the result of
> String>>#asDate and TimeStamp>>date are both Dates but the Dates hold
> instances of different classes as their start values (more on this in a
> moment); DateAndTime and TimeStamp respectively.
>
> So this brings up the question: Why do we have both DateAndTime and
> TimeStamp?  The class comments on both are effectively identical, in
> fact TimeStamp is a subclass of DateAndTime and defines a few accessor
> methods but no additional instance variables.  I suspect the reason is
> historical, that one is a Squeak-ism and another is per ANSI Smalltalk.
>
> The problem occurs in the definition of DateAndTime>>#asDate which is
> simply "^ Date starting: self" and Date class>>#starting: simply assumes
> it's argument is a DateAndTime and stores a reference to it as passed.
> TimeStamp does not redefine #asDate and as such the result of sending
> #asDate to a TimeStamp instance is a date referencing a TimeStamp as
> it's start value.  Other conversions to Date will have DateAndTime
> instances as their start values.
>
> So I can see 2 solutions to this, I feel that in fact both should be
> implemented.
>
> 1.  TimeStamp should define #asDate converting itself to a DateAndTime
> in the process.
>
> 2.  a TimeStamp and DateAndTime referencing equivalent instances in time
> should be equivalent.
>
> Minor rant: Does it really makes sense that a Date is a TimeSpan with a
> fixed 1 day length?
>
> Thoughts?
>
> Ken
>
>
>

> Hi Chris,
>
> I have to admit it had not really occurred to me to consider TimeStamp
> redundant and a candidate for removal, although I can see your point.
> It appears from the thread you link to that it is marked for removal
> from Pharo and possibly has been given this discussion was from April.
>
> I did in fact implement what I discussed below so all Chronology tests
> pass now and that is in Trunk.
>
> I haven't yet checked the image to see if TimeStamp is used internally,
> but assuming it is not (and even if it is that can be fixed without too
> much trouble I expect) then the question becomes if anyone is relying on
> it externally.
>
> Users of TimeStamp, consider this a call for your comments regarding the
> possibility of removing or at least deprecating TimeStamp in Squeak for
> 4.2.

>
> Ken
>
> On Thu, 2010-09-16 at 13:03 -0500, Chris Muller wrote:
>> Hi Ken.  Brent Pinkney, the author of Chronology, agrees that
>> TimeStamp is redundant and should be removed.
>>
>>   http://www.mail-archive.com/pharo-project@.../msg25308.html
>>
>> Since you just did some work on it, I won't remove it myself, but if
>> you want remove it and the test, I support that.
>>
>>  - Chris
>>
>>
>> On Fri, Sep 10, 2010 at 6:31 PM, Ken Causey <[hidden email]> wrote:
>>> I haven't been Squeaking much for a while but for some reason I got the
>>> urge to exercise and break off a little rust so I thought I would look
>>> at a few failing tests in Trunk and see if I could address one or two.
>>> I've had a little success (barring personal misunderstanding) with a
>>> couple in the last two days but I ran into TimeStampTest>>#testAccessing
>>> and learned about a whole new level of 'not understanding'.
>>>
>>> The test itself seems simple enough; compare the date and time parts of
>>> a prepared TimeStamp value to 'literal' values that should be
>>> equivalent.  The test fails and weirdly enough because the result of
>>> String>>#asDate and TimeStamp>>date are both Dates but the Dates hold
>>> instances of different classes as their start values (more on this in a
>>> moment); DateAndTime and TimeStamp respectively.
>>>
>>> So this brings up the question: Why do we have both DateAndTime and
>>> TimeStamp?  The class comments on both are effectively identical, in
>>> fact TimeStamp is a subclass of DateAndTime and defines a few accessor
>>> methods but no additional instance variables.  I suspect the reason is
>>> historical, that one is a Squeak-ism and another is per ANSI Smalltalk.
>>>
>>> The problem occurs in the definition of DateAndTime>>#asDate which is
>>> simply "^ Date starting: self" and Date class>>#starting: simply assumes
>>> it's argument is a DateAndTime and stores a reference to it as passed.
>>> TimeStamp does not redefine #asDate and as such the result of sending
>>> #asDate to a TimeStamp instance is a date referencing a TimeStamp as
>>> it's start value.  Other conversions to Date will have DateAndTime
>>> instances as their start values.
>>>
>>> So I can see 2 solutions to this, I feel that in fact both should be
>>> implemented.
>>>
>>> 1.  TimeStamp should define #asDate converting itself to a DateAndTime
>>> in the process.
>>>
>>> 2.  a TimeStamp and DateAndTime referencing equivalent instances in time
>>> should be equivalent.
>>>
>>> Minor rant: Does it really makes sense that a Date is a TimeSpan with a
>>> fixed 1 day length?
>>>
>>> Thoughts?
>>>
>>> Ken
>>>
>>>
>>>
>>
>>
>
>