On Mon, Sep 15, 2014 at 4:04 PM, Chris Muller <asqueaker at gmail.com> wrote:

> On Sun, Sep 14, 2014 at 12:30 AM, Chris Cunningham
> <cunningham.cb at gmail.com> wrote:
> > This changes adds test for things like
> > DateAndTime now + 2 days
> > and
> > DateAndTime now + 2
> > (the later of which adds two nanoSeconds - who would have guessed?)

...

> > 4> A failure in TestSubtractTimespan.  Currently, Squeak treats adding a
> > Timespan to the DateAndTime as adding the span of time represented by
> > Timespan to the DateAndTime.  It treats subtracting the same as if you
> > wanted the difference between the DateAndTime and the first (starting)
> > dateAndTime of the TimeSpan.  I would assume what is really wanted would
> be
> > to subract the space of time from the DateAndTime instead.  Does anyone
> > dissagree with this desire?
>
> No.  I mean, yes, I disagree.  Timespans represent points-in-time of a
> particular duration (as you know).  Just as adding two DateAndTime's
> together doesn't make a lot of sense, but *subtracting* them does,
> subtracting a TimeSpan from a DateAndTime makes sense but adding a
> TimeSpan was made to be "conveniently" sensible.  Neither one is
> wrong, but there is a lot of code where the interplay between Dates
> and DateAndTime's might be expected to behave similarly as
> DateAndTime's with other DateAndTime's.  For example:
>
>    DateAndTime now - purchaseDate > 90 days ifTrue: [ ^ 'Warranty expired'
> ].
>
> where purchaseDate is a Date.  Its very reasonable to expect for the
> other Timespan types like
>
>     DateAndTime now - ('3/1/2014' asMonth)
>
> to subtract the start of March, 2014 from #now.  Changing or
> redefining that behavior to subtract the duration is not any more
> sensible than treating it as the start, but would break a lot of code.
>
> Hi Chris, yes, this looks right.  I had just looked at Timespan without
looking at its subclasses, and tried building one like:
    Timespan starting: Date today duration: 3 days
 Building it this way isn't as obvious as, say, Date today (which is
definitely something I'd like to compare against the start!).

The subclass Schedule is kinda odd - we'll check the different between the
date and the start of the schedule, but it still make sense IF it is
documented that way.

In line with the other suggestion - basically expecting errors for
odd/unexpected combinations (like expecting the string to be a date/time
for subtracting, and a time/duration string for addition), what do you
think about adding Timespans or DateAndTimes to durations, such as:
1 hour + DateAndTime now
?  It tries to just add the duration part of the second operand tot he
duration - which is weird.  So:
Date today + Date today = Date today
I would think these should raise errors as well.

And thank YOU for sending me off on this path int he first place, and for
the considered reply to what I'm trying to do.

-cbc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140918/2f1ddb3c/attachment.htm