Re: [Pharo-project] (aDateAndTime offset: '0:12:00:00') = '1901-01-01T00:00:00+12:00'
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.duca...@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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] (aDateAndTime offset: '0:12:00:00') = '1901-01-01T00:00:00+12:00'
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] (aDateAndTime offset: '0:12:00:00') = '1901-01-01T00:00:00+12:00'
2010/3/17 stephane ducasse stephane.duca...@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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] (aDateAndTime offset: '0:12:00:00') = '1901-01-01T00:00:00+12:00'
On 17 March 2010 13:13, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: 2010/3/17 stephane ducasse stephane.duca...@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. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] (aDateAndTime offset: '0:12:00:00') = '1901-01-01T00:00:00+12:00'
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
