<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Sep 15, 2014 at 4:04 PM, Chris Muller <span dir="ltr"><<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Sun, Sep 14, 2014 at 12:30 AM, Chris Cunningham<br>
<<a href="mailto:cunningham.cb@gmail.com">cunningham.cb@gmail.com</a>> wrote:<br>
> This changes adds test for things like<br>
> DateAndTime now + 2 days<br>
> and<br>
> DateAndTime now + 2<br>
> (the later of which adds two nanoSeconds - who would have guessed?)</span></blockquote><div>...</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> 4> A failure in TestSubtractTimespan. Currently, Squeak treats adding a<br>
> Timespan to the DateAndTime as adding the span of time represented by<br>
> Timespan to the DateAndTime. It treats subtracting the same as if you<br>
> wanted the difference between the DateAndTime and the first (starting)<br>
> dateAndTime of the TimeSpan. I would assume what is really wanted would be<br>
> to subract the space of time from the DateAndTime instead. Does anyone<br>
> dissagree with this desire?<br>
<br>
</span>No. I mean, yes, I disagree. Timespans represent points-in-time of a<br>
particular duration (as you know). Just as adding two DateAndTime's<br>
together doesn't make a lot of sense, but *subtracting* them does,<br>
subtracting a TimeSpan from a DateAndTime makes sense but adding a<br>
TimeSpan was made to be "conveniently" sensible. Neither one is<br>
wrong, but there is a lot of code where the interplay between Dates<br>
and DateAndTime's might be expected to behave similarly as<br>
DateAndTime's with other DateAndTime's. For example:<br>
<br>
DateAndTime now - purchaseDate > 90 days ifTrue: [ ^ 'Warranty expired' ].<br>
<br>
where purchaseDate is a Date. Its very reasonable to expect for the<br>
other Timespan types like<br>
<br>
DateAndTime now - ('3/1/2014' asMonth)<br>
<br>
to subtract the start of March, 2014 from #now. Changing or<br>
redefining that behavior to subtract the duration is not any more<br>
sensible than treating it as the start, but would break a lot of code.<br>
<span class=""><br></span></blockquote><div>Hi Chris, yes, this looks right. I had just looked at Timespan without looking at its subclasses, and tried building one like:</div><div> Timespan starting: Date today duration: 3 days</div><div> Building it this way isn't as obvious as, say, Date today (which is definitely something I'd like to compare against the start!).</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div>1 hour + DateAndTime now</div><div>? It tries to just add the duration part of the second operand tot he duration - which is weird. So:</div><div>Date today + Date today = Date today</div><div>I would think these should raise errors as well.</div><div><br></div><div>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.</div><div><br></div><div>-cbc</div></div></div></div>