[Pharo-project] 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
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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <brent@zamail.co.za> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <brent@zamail.co.za> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <stephane.ducasse@inria.fr> 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 <brent@zamail.co.za> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <asqueaker@gmail.com> 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 <stephane.ducasse@inria.fr> 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 <brent@zamail.co.za> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <asqueaker@gmail.com> 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 <stephane.ducasse@inria.fr> 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 <brent@zamail.co.za> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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 <brent@zamail.co.za> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
What is Timestamp? On Fri, Apr 23, 2010 at 3:25 PM, Henrik Johansen <henrik.s.johansen@veloxit.no> 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 <brent@zamail.co.za> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
it will be :) http://code.google.com/p/pharo/issues/detail?id=2348 On Apr 23, 2010, at 11:18 PM, Brent Pinkney wrote:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Apr 23, 2010, at 10:25 PM, Henrik Johansen 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
:) Stef
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 <brent@zamail.co.za> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/4/23 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
+1 Stef On Apr 23, 2010, at 9:51 PM, Nicolas Cellier wrote:
2010/4/23 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <stephane.ducasse@inria.fr>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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 <stephane.ducasse@inria.fr> 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 <stephane.ducasse@inria.fr>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Indeed this would be good to fold TimeStamp in its superclass. I was not aware of this situation but now we will fix it. May be some care is needed to keep the nice printout of TimeStamp. If you have some pharo code send it. Stef On Apr 23, 2010, at 11:36 PM, Chris Muller wrote:
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 <stephane.ducasse@inria.fr> 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 <stephane.ducasse@inria.fr>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (5)
-
Brent Pinkney -
Chris Muller -
Henrik Johansen -
Nicolas Cellier -
Stéphane Ducasse