Smalltalk › Pharo › Pharo Smalltalk Developers

(aDateAndTime offset: '0:12:00:00') = '1901-01-01T00:00:00+12:00'

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

stephane ducasse

(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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nicolas Cellier

Re: (aDateAndTime offset: '0:12:00:00') = '1901-01-01T00:00:00+12:00'

2010/3/17 stephane ducasse <[hidden email]>:

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

Igor Stasenko

Re: (aDateAndTime offset: '0:12:00:00') = '1901-01-01T00:00:00+12:00'

On 17 March 2010 13:13, Nicolas Cellier
<[hidden email]> wrote:

> 2010/3/17 stephane ducasse <[hidden email]>:
>> 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
>> [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
>

--
Best regards,
Igor Stasenko AKA sig.

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

Stéphane Ducasse

Re: (aDateAndTime offset: '0:12:00:00') = '1901-01-01T00:00:00+12:00'

In reply to this post by Nicolas Cellier

>
> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Carla F. Griggio

Re: (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 <[hidden email]> 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
[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: (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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project