[squeak-dev] TimeSpan and DateAndTime? Date is a TimeSpan with a duration of 1 day? aka TimeStampTest>>#testAccessing failure

Chris Muller asqueaker at gmail.com
Thu Sep 16 18:03:03 UTC 2010


Hi Ken.  Brent Pinkney, the author of Chronology, agrees that
TimeStamp is redundant and should be removed.

  http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/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 <ken at kencausey.com> 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
>
>
>



More information about the Squeak-dev mailing list