[Pharo-project] (aDateAndTime offset: '0:12:00:00') = '1901-01-01T00:00:00+12:00'
in Squeak (aDateAndTime offset: '0:12:00:00') = '1901-01-01T00:00:00+12:00' true in pharo (aDateAndTime offset: '0:12:00:00') = '1901-01-01T00:00:00+12:00'. false. Apparently the false in pharo comes from a bug in readFrom: in DateAndTime Now the question is does it make sense to have a DateAndTime = to its string representation. For me I would prefer not (aDateAndTime offset: '0:12:00:00') = '1901-01-01T00:00:00+12:00' -> false (aDateAndTime offset: '0:12:00:00') printString = '1901-01-01T00:00:00+12:00' -> true DateAndTime>>= comparand "comparand conforms to protocol DateAndTime, or can be converted into something that conforms." | comparandAsDateAndTime | self == comparand ifTrue: [^ true]. comparandAsDateAndTime := [comparand asDateAndTime] on: MessageNotUnderstood do: [^ false]. ^ self offset = comparandAsDateAndTime offset ifTrue: [self hasEqualTicks: comparandAsDateAndTime ] ifFalse: [self asUTC ticks = comparandAsDateAndTime asUTC ticks] What do you think Stef
2010/3/17 stephane ducasse <stephane.ducasse@free.fr>:
in Squeak
    (aDateAndTime offset: '0:12:00:00') =  '1901-01-01T00:00:00+12:00'     true
in pharo
    (aDateAndTime offset: '0:12:00:00') =  '1901-01-01T00:00:00+12:00'.     false.
Apparently the false in pharo comes from a bug in readFrom: in DateAndTime
Now the question is does it make sense to have a DateAndTime = to its string representation. For me I would prefer not
    (aDateAndTime offset: '0:12:00:00') =  '1901-01-01T00:00:00+12:00'     -> false     (aDateAndTime offset: '0:12:00:00') printString  =  '1901-01-01T00:00:00+12:00'     -> true
DateAndTime>>= comparand     "comparand conforms to protocol DateAndTime,     or can be converted into something that conforms."     | comparandAsDateAndTime |     self == comparand         ifTrue: [^ true].     comparandAsDateAndTime := [comparand asDateAndTime]         on: MessageNotUnderstood         do: [^ false].     ^ self offset = comparandAsDateAndTime offset         ifTrue: [self hasEqualTicks: comparandAsDateAndTime ]         ifFalse: [self asUTC ticks = comparandAsDateAndTime asUTC ticks]
What do you think
I would expect = to be "reflexive" self assert: (a = a). "symmetric" self assert: (a = b) ==> (b = a). "transitive" self assert: (a = b) & (b = c) ==> (a = c). Date>>= does not seem to meet my expectations
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 17 March 2010 13:13, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2010/3/17 stephane ducasse <stephane.ducasse@free.fr>:
in Squeak
    (aDateAndTime offset: '0:12:00:00') =  '1901-01-01T00:00:00+12:00'     true
in pharo
    (aDateAndTime offset: '0:12:00:00') =  '1901-01-01T00:00:00+12:00'.     false.
Apparently the false in pharo comes from a bug in readFrom: in DateAndTime
Now the question is does it make sense to have a DateAndTime = to its string representation. For me I would prefer not
    (aDateAndTime offset: '0:12:00:00') =  '1901-01-01T00:00:00+12:00'     -> false     (aDateAndTime offset: '0:12:00:00') printString  =  '1901-01-01T00:00:00+12:00'     -> true
DateAndTime>>= comparand     "comparand conforms to protocol DateAndTime,     or can be converted into something that conforms."     | comparandAsDateAndTime |     self == comparand         ifTrue: [^ true].     comparandAsDateAndTime := [comparand asDateAndTime]         on: MessageNotUnderstood         do: [^ false].     ^ self offset = comparandAsDateAndTime offset         ifTrue: [self hasEqualTicks: comparandAsDateAndTime ]         ifFalse: [self asUTC ticks = comparandAsDateAndTime asUTC ticks]
What do you think
I would expect = to be "reflexive" Â Â Â self assert: (a = a). "symmetric" Â self assert: (a = b) ==> (b = a). "transitive" Â Â Â self assert: (a = b) & (b = c) ==> (a = c).
yeah, as a Magnitude it should have such properties.
Date>>= does not seem to meet my expectations
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
-- Best regards, Igor Stasenko AKA sig.
I would expect = to be "reflexive" self assert: (a = a). "symmetric" self assert: (a = b) ==> (b = a). "transitive" self assert: (a = b) & (b = c) ==> (a = c).
Date>>= does not seem to meet my expectations
Yes the more I think about it the more I'm against this automatic conversion. Stef
I guess it depends on how you'd like to represent a date and time. We may have 2 representations here, the DateAndTime object and the string. If you consider that the string '1901-01-01T00:00:00+12:00' actually * represents* that day and time and it's not just the way you would print it, then I think it's valid to compare one representation and another of the same concept, because they really *mean* the same to you. If you see '1901-01-01T00:00:00+12:00' and say "that's not a date and time, it's just how I'd print it" maybe the only valid representation of the date and time for you is a DateAndTime object, then it doesn't make sense comparing de DateAndTime object with it's string. Personally, I think the string it's just the "print string", I agree with you. But maybe originally the people who implemented that comparison considered it as a date and time representation too, so it makes sense to compare them. On Wed, Mar 17, 2010 at 10:22 AM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
I would expect = to be "reflexive" self assert: (a = a). "symmetric" self assert: (a = b) ==> (b = a). "transitive" self assert: (a = b) & (b = c) ==> (a = c).
Date>>= does not seem to meet my expectations
Yes the more I think about it the more I'm against this automatic conversion.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mar 19, 2010, at 7:39 AM, Carla F. Griggio wrote:
I guess it depends on how you'd like to represent a date and time. We may have 2 representations here, the DateAndTime object and the string. If you consider that the string '1901-01-01T00:00:00+12:00' actually represents that day and time and it's not just the way you would print it, then I think it's valid to compare one representation and another of the same concept, because they really mean the same to you.
we are in object-oriented programming not string oriented programming so this is not valid to a date and its string representation to be equal. :)
If you see '1901-01-01T00:00:00+12:00' and say "that's not a date and time, it's just how I'd print it" maybe the only valid representation of the date and time for you is a DateAndTime object, then it doesn't make sense comparing de DateAndTime object with it's string.
exact!!!
Personally, I think the string it's just the "print string", I agree with you. But maybe originally the people who implemented that comparison considered it as a date and time representation too, so it makes sense to compare them
they probably wanted to do too much. Stef
participants (5)
-
Carla F. Griggio -
Igor Stasenko -
Nicolas Cellier -
stephane ducasse -
Stéphane Ducasse