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@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
> >
> >
> >
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100916/bedcdba9/attachment.pgp