about DateAndTime =

> I'm turning this into tests!
> Brent if you want to help fixing let me know.
> I will focus now on the parsing problem.
>
> Stef
>
> On Apr 23, 2010, at 9:51 PM, Nicolas Cellier wrote:
>
>> 2010/4/23 Stéphane Ducasse <[hidden email]>:
>>> Hi all
>>>
>>> I'm trying to fix some tests and I do not like the behavior of DateAndTime =
>>> Comparing aDateAndTime and a something tries to convert the something in a dateAndTime automagically.
>>> I find that not really good because it hides potential problem: manipulating string instead of objects.
>>>
>>> So I would like to have
>>>        (aDateAndTime offset: '0:12:00:00') =  '1901-01-01T00:00:00+12:00' -> false
>>>        (aDateAndTime offset: '0:12:00:00') asString =  '1901-01-01T00:00:00+12:00' -> true.
>>>
>>> What do you think.
>>>
>>
>> I would expect this for =
>> 1) Reflexive
>>    self assert: x = x.
>> 2) Symmetric
>>    self assert: (x = y) = (y = x).
>> 3) Transitive
>>    self assert: (x = y) & (y = z) ==> (x = z).
>>
>> I guess equality with a String at least breaks 2).
>>
>> Nicolas
>>
>>
>>> Stef
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

>
> Cheers,
> Henry
>
> On Apr 23, 2010, at 10:01 30PM, Stéphane Ducasse wrote:
>
>> Thanks
>>
>> Chris about the speed what do you compare?
>> using accessors to access month/date or something else.
>> This is not clear to me.
>>
>> On Apr 23, 2010, at 9:49 PM, Chris Muller wrote:
>>
>>> In case anyone cares, Brent and I have been working together
>>> professionally for the last couple of years.  Brent, we have been
>>> running with that method modified since 2007 to not do that
>>> conversion.  We have not sufferred any ill-effects from it.  Check our
>>> vanilla image:
>>>
>>> DateAndTime>>#= comparand
>>> "comparand conforms to protocol DateAndTime,
>>> or can be converted into something that conforms."
>>> | comparandAsDateAndTime |
>>> self == comparand ifTrue: [ ^ true ].
>>> (comparand isKindOf: self class) ifFalse: [ ^ false ].
>>> [ comparandAsDateAndTime := comparand asDateAndTime ]
>>> on: MessageNotUnderstood
>>> do: [ ^ false ].
>>> ^ self offset = comparandAsDateAndTime offset
>>> ifTrue: [ self hasEqualTicks: comparandAsDateAndTime ]
>>> ifFalse: [ self asUTC ticks = comparandAsDateAndTime asUTC ticks ]
>>>
>>> I agree with Stef on this.  Not only is it confusing to me, it is
>>> inconsistent with other type-checks.  But the primary reason I
>>> overrode it back in 2007 was for better performance.  Try benching the
>>> above against the stock comparison...
>>>
>>> - Chris
>>>
>>> On Fri, Apr 23, 2010 at 2:26 PM, Brent Pinkney <[hidden email]> wrote:
>>>> On Friday 23 April 2010 21:12:03 Stéphane Ducasse wrote:
>>>>> Hi all
>>>>>
>>>>> I'm trying to fix some tests and I do not like the behavior of DateAndTime
>>>>> = Comparing aDateAndTime and a something tries to convert the something in
>>>>> a dateAndTime automagically. I find that not really good because it hides
>>>>> potential problem: manipulating string instead of objects.
>>>>>
>>>>> So I would like to have
>>>>>     (aDateAndTime offset: '0:12:00:00') =  '1901-01-01T00:00:00+12:00' ->
>>>>> false (aDateAndTime offset: '0:12:00:00') asString =
>>>>> '1901-01-01T00:00:00+12:00' -> true.
>>>>>
>>>>> What do you think.
>>>>
>>>> Hi,
>>>>
>>>> I wrote that code, and it is needed to compare DateAndTimes with Timespans - eg Month, Year, Date...
>>>> Please tread carefully - lots of production code relies on that.
>>>>
>>>> Already my (DateAndTime now != DateAndTime now)  have been removed :(
>>>>
>>>> Thanks
>>>>
>>>> Brent
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>> What is Timestamp?
>
> A legacy class that has a Date and a TIme object.
> Predates ANSI DateAndTime.
>
> Should be purged IMHO.
>
> Brent
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Hi Stef, I will help on the Squeak side.  I suppose I could work on
> that symmetry with Timestamp, but I'd rather talk about removing
> Timestamp instead first..  It doesn't really seem like we need two
> time-stamp classes, do we?
>
>
>
> On Fri, Apr 23, 2010 at 3:06 PM, Stéphane Ducasse
> <[hidden email]> wrote:
>> I'm turning this into tests!
>> Brent if you want to help fixing let me know.
>> I will focus now on the parsing problem.
>>
>> Stef
>>
>> On Apr 23, 2010, at 9:51 PM, Nicolas Cellier wrote:
>>
>>> 2010/4/23 Stéphane Ducasse <[hidden email]>:
>>>> Hi all
>>>>
>>>> I'm trying to fix some tests and I do not like the behavior of DateAndTime =
>>>> Comparing aDateAndTime and a something tries to convert the something in a dateAndTime automagically.
>>>> I find that not really good because it hides potential problem: manipulating string instead of objects.
>>>>
>>>> So I would like to have
>>>>       (aDateAndTime offset: '0:12:00:00') =  '1901-01-01T00:00:00+12:00' -> false
>>>>       (aDateAndTime offset: '0:12:00:00') asString =  '1901-01-01T00:00:00+12:00' -> true.
>>>>
>>>> What do you think.
>>>>
>>>
>>> I would expect this for =
>>> 1) Reflexive
>>>   self assert: x = x.
>>> 2) Symmetric
>>>   self assert: (x = y) = (y = x).
>>> 3) Transitive
>>>   self assert: (x = y) & (y = z) ==> (x = z).
>>>
>>> I guess equality with a String at least breaks 2).
>>>
>>> Nicolas
>>>
>>>
>>>> Stef
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>