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