Smalltalk › Pharo › Pharo Smalltalk Users

Date offset in Glorp and RDBMS

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

eftomi

Date offset in Glorp and RDBMS

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

Sven Van Caekenberghe-2

Re: Date offset in Glorp and RDBMS

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 <[hidden email]> 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
>

Esteban A. Maringolo

Re: Date offset in Glorp and RDBMS

+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 <[hidden email]> 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 <[hidden email]> 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
> >
>
>

eftomi

Re: Date offset in Glorp and RDBMS

Thanks for the clues! At first glance, I'd say that the testing could be
changed into #equals since the majority of date related tests are not
focused into timezones - for instance, one of these tests is
GlorpObjectMappedToImaginaryTableTest>>#testReadBackEntireExample which
sends #assertEqual: to subclass of GlorpTestModelClasses. These
#assertEqual: methods look like

GlorpVideoCreditStatus>>#assertEqual: aCreditStatus
self assert: customer name = aCreditStatus customer name.
self assert: customer dateOfBirth = aCreditStatus customer dateOfBirth.
self assert: balanceOwing = aCreditStatus balanceOwing.
self assert: dateOwing = aCreditStatus dateOwing.
self assert: comments = aCreditStatus comments.

There might be some specific test on timezones, though, Glorp has a huge
testing package.

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

eftomi

Re: Date offset in Glorp and RDBMS

Actually, the issue was with reading the variant Date and creating a
DateAndTime object by directly setting the JulianDayNumber without respect
to the timezone. I commited the necessary change to PharoCOM
<https://github.com/tesonep/pharo-com> .

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html