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