+1 to #equals:, it is for that purpose. However it might be the case that Glorp is testing a type that is expected to have an offset/timezone, in which case you'd be "eating" the error if the cell value contains a timezone different than the one in your image. Esteban A. Maringolo On Sun, Dec 29, 2019 at 9:46 AM Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi Tomaz,
Consider
DateAndTime now asUTC asDate = Date today.
which is false (on most systems), while
DateAndTime now asUTC asDate equals: Date today.
is true. #equals was added specifically for that purpose (ignore the offset).
Note also that an abstract date (year/month/day) does not exist without the context of a proper timezone (an offset is not enough).
Sven
On 29 Dec 2019, at 13:29, eftomi <tomaz.turk@ef.uni-lj.si> wrote:
Dear all,
Going through the remaining red tests in PharoADO + Glorp, I have a sort of a conceptual challenge. Some of the Glorp tests are checking the equality of dates written to and then returned from the database. Pharo regards the dates as not equal if their time offsets are different despite the fact that the date (in a narrow sense) is the same. For instance:
"2019-12-29T00:00:00+01:00"
is not equal to
"2019-12-29T00:00:00+00:00"
The challenge is that the ActiveX Data Objects (ADO) library that I'm using returnes the dates in Variants which don't have any information about the offset. The conversion from ADO variants to Pharo's Date is done in PharoCOM package.
What would be the best approach to somehow ignore the missing offset or impute a proper value? Of course it's better to ignore a missing data than to impute a wrong value. How is this handled with other DB systems?
Thanks, Tomaz
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html