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?)

Agree with Nico, this should be an exception.

> IT mostly tests to the current results of the most current Trunk, with a few
> exceptions:
> 1> Tests adding Months and Years, which currenty isn't supported (causes 13
> errors), which are fixed in additional changes (covered in another email).
> If those changes are not acceptable, I can remove them....

It seems like those enhancements would not cause any regressions.  Is
that true?  If so, I'm liking them more and more.  ;)

> 2> And error on TestSubtractString.  Currently, it treats adding strings as
> if they were durations, but since String responds to #asDateAndTime, it
> treats them as if they were DateAndTime strings.  I'd rather see them as
> durations in both cases, so expected to see it as a duration for
> subtracting, which causes an error.  If this is wrong and the general
> expectation is that they should be DateAndTimes for subtracting and
> Durations for adding, I can change the test.  (But it is really confusing
> and not clear!)

Back in 2010, we abandoned the ability to compare a DateAndTime to a
String.  Allowing it caused a horrible performance penalty, even when
not comparing to a String.

I think we should do the same w.r.t. any other comparisons  (e.g., #<)
as well as the ariethmetic operators.  Let the *user* of the
DateAndTime send #asDateAndTime himself, rather than punish everyone
else.  Type conversions like that should be explicit anyway, not
implicit.

IMO, passing a String into DateAndTime>>#- or #+ should raise an error.

DateAndTime>>#- should only accept EITHER another DateAndTime (which
would answer a Duration) or a Duration (which would answer a
DateAndTime) or a Timespan.

> 3> A failure in TestSubtractTime.  Currently, Squeak treats adding a time as
> adding the time to the DateAndTime; but it treats subtracting a time as
> trying to figure out the difference between the DateAndTime and a a
> DateAndTime of the current date with the time portion set to the time.  This
> is conterintuitive - does anyone expect this (or see any reason it would
> make sense)?  I have setup the test to treat it as if we wanted to jut
> subtract whatever the time is from the DateAndTime.

For me, arithmetic between DateAndTime and Time does not make a lot of
sense.  Unless someone has a sensible use-case, I'm leaning toward it
should be an error.

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

> If these tests are acceptable, I can modify the behaviour to match the
> tests.  If the current behaviour is correct, however, I can alter the tests
> to match that behaviour.  What is the consensus?

Thanks for doing this work and for gathering consensus!

> In either case, I would like to see these tests (possibly sanitized) added
> to Trunk, please.

Okay.