Smalltalk › Pharo › Pharo Smalltalk Developers

about DateAndTime =

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

25 messages Options

Stéphane Ducasse

about DateAndTime =

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.

Stef
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Brent Pinkney-2

Re: about DateAndTime =

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

Stéphane Ducasse

Re: about DateAndTime =

On Apr 23, 2010, at 9:26 PM, Brent Pinkney 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.

Thanks for the info.
Now I think that strings are dead objects and we should not use them in place of real ones.

> Already my (DateAndTime now != DateAndTime now) have been removed :(

was it in 3.9?

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

Henrik Sperre Johansen

Re: about DateAndTime =

In reply to this post by Brent Pinkney-2

On Apr 23, 2010, at 9:26 31PM, Brent Pinkney wrote:

Because even if the resolution of a DateAndTime is nanoseconds, the clock available to derive now from has a resolution of milliseconds (microseconds using an updated VM on some platforms). (Not to mention the now method actually uses a second resolution...)

Thus a test which states that asking for now two times in a row should always result in different DateAndTime values does not make sense.

Cheers,
Henry
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Stéphane Ducasse

Re: about DateAndTime =

In reply to this post by Brent Pinkney-2

Hi brent

>>
> Hi,
>
> I wrote that code, and it is needed to compare DateAndTimes with Timespans - eg Month, Year, Date...

Do you have examples? For month I have problems,
Then I wonder why

aDateAndTime = aMonth
is better
than
aDateAndTime month = aMonth

> Please tread carefully - lots of production code relies on that.

did you mean that production code rely on string automatic conversion when compared to?

>
> Already my (DateAndTime now != DateAndTime now) have been removed :(

Apparently it was not in 3.9 so I do not know when it was removed but this was not in pharo.
Then finally if you do not raise the issue we are not omniscient so we cannot know it.

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

Chris Muller-3

Re: about DateAndTime =

In reply to this post by Brent Pinkney-2

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:

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Brent Pinkney-2

Re: about DateAndTime =

In reply to this post by Stéphane Ducasse

> Do you have examples? For month I have problems,
> Then I wonder why
>
> aDateAndTime = aMonth
> is better
> than
> aDateAndTime month = aMonth

Hi, Chris Muller has just told me that I am dead wron on the equality issue, so I stand corrected. He will post soon.

On the above, this is a bit of archeology - the Month and Week classes were introduced into Squeak before I added the ANSI
Chronology classes and the whole Timespan hierarchy.

I could only get the chronology into the image by preserving compatibility.

It could probably be refactored now.

Brent

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nicolas Cellier

Re: about DateAndTime =

In reply to this post by Stéphane Ducasse

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

Stéphane Ducasse

Re: about DateAndTime =

In reply to this post by Henrik Sperre Johansen

Thanks for the explanation.

Stef

On Apr 23, 2010, at 9:37 PM, Henrik Johansen wrote:

>
> On Apr 23, 2010, at 9:26 31PM, Brent Pinkney 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
> Because even if the resolution of a DateAndTime is nanoseconds, the clock available to derive now from has a resolution of milliseconds (microseconds using an updated VM on some platforms). (Not to mention the now method actually uses a second resolution...)
>
> Thus a test which states that asking for now two times in a row should always result in different DateAndTime values does not make sense.
>
> Cheers,
> Henry
> _______________________________________________
> 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

Stéphane Ducasse

Re: about DateAndTime =

In reply to this post by Henrik Sperre Johansen

Now I'm more fighting with

(Duration readFrom: '0:00:00:00.001 ' readStream) nanoSeconds -> 1
http://code.google.com/p/pharo/issues/detail?id=1202

as well as
self assert: (DateAndTime readFrom: '1901-01-01T00:00:00+12:00' readStream) asString -> '1901-01-01T00:00:00+02:00'

;)

which works in squeak!

Stef

On Apr 23, 2010, at 9:37 PM, Henrik Johansen wrote:

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Stéphane Ducasse

Re: about DateAndTime =

In reply to this post by Chris Muller-3

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

Stéphane Ducasse

Re: about DateAndTime =

In reply to this post by Brent Pinkney-2

in Pharo1.0

= comparand
"comparand conforms to protocol DateAndTime,
or can be converted into something that conforms."
| comparandAsDateAndTime |
self == comparand ifTrue: [ ^ true ].
----> this one is absent: (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 ]

Now I would love to understand what is slower than that :)

>
> Hi, Chris Muller has just told me that I am dead wron on the equality issue, so I stand corrected. He will post soon.
>
> On the above, this is a bit of archeology - the Month and Week classes were introduced into Squeak before I added the ANSI
> Chronology classes and the whole Timespan hierarchy.
>
> I could only get the chronology into the image by preserving compatibility.
>
> It could probably be refactored now.

Please send us some code because this would be good to have it straight now. :)

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

Stéphane Ducasse

Re: about DateAndTime =

In reply to this post by Nicolas Cellier

+1

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

Stéphane Ducasse

Re: about DateAndTime =

In reply to this post by Nicolas Cellier

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:

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Chris Muller-3

Re: about DateAndTime =

In reply to this post by Stéphane Ducasse

By having added the type-check into the method:

(comparand isKindOf: self class) ifFalse: [ ^ false ].

the speed of testing a DateAndTime against other objects is improved
because it avoids that whole business of attempting to convert the
object and trapping Error to return false...

Did you try it?

|dt| dt:=DateAndTime now.
[ dt = 'hello' ] bench

'492680.6638672266 per second.' (mine) vs. '34438.5122975405 per
second.' (with attempted conversion)

On Fri, Apr 23, 2010 at 3:01 PM, Stéphane Ducasse
<[hidden email]> 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

Chris Muller-3

Re: about DateAndTime =

I just noticed I used 'hello' instead of Obejct new, so I'll clarify..
this is not about comparing Dates to Strings. It is faster in
comparing against _any_ othe robject than a DateAndTime. This is
important not only for system and compiler stuff working, but also for
applications which make use of heterogeneous collections of objects...

On Fri, Apr 23, 2010 at 3:08 PM, Chris Muller <[hidden email]> wrote:

> By having added the type-check into the method:
>
> (comparand isKindOf: self class) ifFalse: [ ^ false ].
>
> the speed of testing a DateAndTime against other objects is improved
> because it avoids that whole business of attempting to convert the
> object and trapping Error to return false...
>
> Did you try it?
>
> |dt| dt:=DateAndTime now.
> [ dt = 'hello' ] bench
>
> '492680.6638672266 per second.' (mine) vs. '34438.5122975405 per
> second.' (with attempted conversion)
>
> On Fri, Apr 23, 2010 at 3:01 PM, Stéphane Ducasse
> <[hidden email]> 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

Stéphane Ducasse

Re: about DateAndTime =

In reply to this post by Chris Muller-3

On Apr 23, 2010, at 10:08 PM, Chris Muller wrote:

> |dt| dt:=DateAndTime now.
> [ dt = 'hello' ] bench

I get

|dt| dt:=DateAndTime now.
[ dt = 'hello' ] bench '49063.3873225355 per second.'

:)

Ok I see. Now my point was more in the idea to compare strings with other objects.
I could understand with lot of imagination that you want to compare a dt and a month.
But not a string.

Stef
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Stéphane Ducasse

Re: about DateAndTime =

In reply to this post by Chris Muller-3

On Apr 23, 2010, at 10:11 PM, Chris Muller wrote:

> I just noticed I used 'hello' instead of Obejct new, so I'll clarify..
> this is not about comparing Dates to Strings. It is faster in
> comparing against _any_ othe robject than a DateAndTime. This is
> important not only for system and compiler stuff working, but also for
> applications which make use of heterogeneous collections of objects...

yes I got it.
I integrated your version. But I would like the properties mentioned by nicolas for comparison.
Else we break something important for the sake of a certain lazilyness.

Stef

>
> On Fri, Apr 23, 2010 at 3:08 PM, Chris Muller <[hidden email]> wrote:
>> By having added the type-check into the method:
>>
>> (comparand isKindOf: self class) ifFalse: [ ^ false ].
>>
>> the speed of testing a DateAndTime against other objects is improved
>> because it avoids that whole business of attempting to convert the
>> object and trapping Error to return false...
>>
>> Did you try it?
>>
>> |dt| dt:=DateAndTime now.
>> [ dt = 'hello' ] bench
>>
>> '492680.6638672266 per second.' (mine) vs. '34438.5122975405 per
>> second.' (with attempted conversion)
>>
>> On Fri, Apr 23, 2010 at 3:01 PM, Stéphane Ducasse
>> <[hidden email]> 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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Henrik Sperre Johansen

Re: about DateAndTime =

In reply to this post by Stéphane Ducasse

It's still wrong though, in that it is not symmetric...

Due to the isKindOf: self class test, and
= not being reimplemented in Timestamp (DateAndTime subclass), so Timestamp to DateAndTime comparitions will fail:

aDateandTime = anEquivalentTimestamp true
anEquivalentTimestamp = aDateAndTime false

There's a test for you! :D

Cheers,
Henry

On Apr 23, 2010, at 10:01 30PM, Stéphane Ducasse wrote:

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Chris Muller-3

Re: about DateAndTime =

What is Timestamp?

On Fri, Apr 23, 2010 at 3:25 PM, Henrik Johansen
<[hidden email]> wrote:

> It's still wrong though, in that it is not symmetric...
>
> Due to the isKindOf: self class test, and
> = not being reimplemented in Timestamp (DateAndTime subclass), so Timestamp to DateAndTime comparitions will fail:
>
> aDateandTime = anEquivalentTimestamp true
> anEquivalentTimestamp = aDateAndTime false
>
> There's a test for you! :D
>
> 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
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project