|
Perhaps the conversions to DateAndTime and Duration should not happen implicitly. Right now we have this complex logic because we want to support things like this:
<code> t := '2004-01-07T11:55:00+00:00' asDateAndTime. t - 5. t - '2004-01-07' </code>
But maybe we shouldn't. It doesn't make much sense to subtract a string or a number (number of what? days? seconds?) from a DateAndTime object. And whoever is using this can easily do an explicit conversion, which, by the way, would also make his code more readable.
<code> t - 5 asDuration. t - '2004-01-07' asTimeAndDate </code>
I've implemented a new version using double dispatch:
<code> DateAndTime >> - operand "Subtracts an operand from itself. The operand can be either another DateAndTime or Duration. In case one DateAndTime is subtracted from the other, we get the Duration between them. In case we subtract Duration from DateAndTime, we get another DateAndTime." ^ operand subtractFromDateAndTime: self.
DateAndTime >> subtractFromDateAndTime: aDateAndTime "Subtracts itself from another DateAndTime object to find the duration between them." ^ Duration seconds: (SecondsInDay * (aDateAndTime julianDayNumberUTC - julianDayNumber)) + (aDateAndTime secondsSinceMidnightUTC - seconds) nanoSeconds: aDateAndTime nanoSecond - nanos.
Duration >> subtractFromDateAndTime: aDateAndTime "Subtracts itself from DateAndTime to get another DateAndTime." ^ aDateAndTime + self negated. </code>
And I suggest that we mark the previous implementation as deprecated because some code might depend on it.
|
|
|
Priority: 5 – Fix If Time
|
|
Status: Work Needed
|
|
Assigned to: Everyone
|
|
Milestone: Pharo7.0
|
Go to Case
|
|