Strange Result - OmniBase bug or Date feature?
Locked
Strange Result - OmniBase bug or Date feature?
 
|
Hello All I am experimenting with the version of OmniBase which Esteban Lorenzano posted a few days ago. With corrections posted by Matias Moretto, who is working on the same track, I have got the first five tests all green. On the sixth test, OmniBaseTest>>#testEquality, I have run into a strange failure. I don’t know whether it shows that OmniBase is not recovering data correctly, or whether it is a feature of the way Date is implemented in Pharo. (I still have Dolphin 6 on my machine, including OmniBase, and there the same test passes.) The test simply constructs a collection of various types of object, stores the whole collection on the database, retrieves it and compares each retrieved element with the corresponding element of the original collection. One element is obtained by evaluating ‘Date today’, and that is the one that fails. The test failure description is: ‘Got 23 June 2018 instead of 23 June 2018.’ Using the inspector, I can see that the retrieved date differs from the original in that the instvar ‘start’ has a Julian Day Number which is one greater, but seconds as zero instead of 82800 and an offset of zero instead of 1:00:00. In fact 82800 seconds is 23 hours, so all these add up to the same start time, just differently represented. To get round the failure, I changed the constructor of the test collection to use ‘Date today printString’, which of course meant it worked perfectly. My worry is whether in some other context the change of the innards of the object might have an adverse effect. I don’t understand why the Date constructor represents the start of today as 23 hours after 1 a.m. yesterday. Is the change something OmniBase has done in storing and retrieving, or is it due to the way the Date is reconstructed? Just for fun, I used Fuel to serialize and re-materialize Date today; it did not make any changes. Does this reinforce Todd’s suggestion that OmniBase is not reliable, or is it just a quirk? Any ideas gratefully received Peter Kenny |
Re: Strange Result - OmniBase bug or Date feature?
|
|
Hi Peter,
On Sat, 23 Jun 2018 at 17:47, PBKResearch <[hidden email]> wrote: > > Hello All > > > > I am experimenting with the version of OmniBase which Esteban Lorenzano posted a few days ago. With corrections posted by Matias Moretto, who is working on the same track, I have got the first five tests all green. On the sixth test, OmniBaseTest>>#testEquality, I have run into a strange failure. I don’t know whether it shows that OmniBase is not recovering data correctly, or whether it is a feature of the way Date is implemented in Pharo. (I still have Dolphin 6 on my machine, including OmniBase, and there the same test passes.) > > > > The test simply constructs a collection of various types of object, stores the whole collection on the database, retrieves it and compares each retrieved element with the corresponding element of the original collection. One element is obtained by evaluating ‘Date today’, and that is the one that fails. The test failure description is: ‘Got 23 June 2018 instead of 23 June 2018.’ Using the inspector, I can see that the retrieved date differs from the original in that the instvar ‘start’ has a Julian Day Number which is one greater, but seconds as zero instead of 82800 and an offset of zero instead of 1:00:00. In fact 82800 seconds is 23 hours, so all these add up to the same start time, just differently represented. > > > > To get round the failure, I changed the constructor of the test collection to use ‘Date today printString’, which of course meant it worked perfectly. My worry is whether in some other context the change of the innards of the object might have an adverse effect. I don’t understand why the Date constructor represents the start of today as 23 hours after 1 a.m. yesterday. Is the change something OmniBase has done in storing and retrieving, or is it due to the way the Date is reconstructed? A Date in Pharo is a 24 hour period and thus the timezone is important, e.g. the start of 23 Jun in London is not the same as 23 Jun in Melbourne. If you want to compare the date using day / month / year and not as a 24 hour period, try using #equals: instead of #=. HTH, Alistair |
Re: Strange Result - OmniBase bug or Date feature?
|
|
Hi Alistair
I am not trying to compare dates, I just want to be sure that OmniBase stores and retrieves dates without altering them. I have done further tests which show that this is not so. By looking at the start time, I find that the original date for today starts at 00:00:00 BST (as it should in London!), whereas after storing and retrieving by OmniBase it starts at 00:00:00 UTC (or GMT), i.e. it has shifted by an hour. This is not very important in itself, but it is worrying that OmniBase can change things. It may be a quirk of the way Date is handled by OmniBase, but it needs further investigation. I can see I shall have endless fun probing how OmniBase stores and retrieves instance variables - luckily I did not have anything major planned for the weekend! Or else I should just follow Todd's advice. Peter Kenny -----Original Message----- From: Pharo-users <[hidden email]> On Behalf Of Alistair Grant Sent: 23 June 2018 17:15 To: Pharo-Users <[hidden email]> Subject: Re: [Pharo-users] Strange Result - OmniBase bug or Date feature? Hi Peter, On Sat, 23 Jun 2018 at 17:47, PBKResearch <[hidden email]> wrote: > > Hello All > > > > I am experimenting with the version of OmniBase which Esteban > Lorenzano posted a few days ago. With corrections posted by Matias > Moretto, who is working on the same track, I have got the first five > tests all green. On the sixth test, OmniBaseTest>>#testEquality, I > have run into a strange failure. I don’t know whether it shows that > OmniBase is not recovering data correctly, or whether it is a feature > of the way Date is implemented in Pharo. (I still have Dolphin 6 on my > machine, including OmniBase, and there the same test passes.) > > > > The test simply constructs a collection of various types of object, stores the whole collection on the database, retrieves it and compares each retrieved element with the corresponding element of the original collection. One element is obtained by evaluating ‘Date today’, and that is the one that fails. The test failure description is: ‘Got 23 June 2018 instead of 23 June 2018.’ Using the inspector, I can see that the retrieved date differs from the original in that the instvar ‘start’ has a Julian Day Number which is one greater, but seconds as zero instead of 82800 and an offset of zero instead of 1:00:00. In fact 82800 seconds is 23 hours, so all these add up to the same start time, just differently represented. > > > > To get round the failure, I changed the constructor of the test collection to use ‘Date today printString’, which of course meant it worked perfectly. My worry is whether in some other context the change of the innards of the object might have an adverse effect. I don’t understand why the Date constructor represents the start of today as 23 hours after 1 a.m. yesterday. Is the change something OmniBase has done in storing and retrieving, or is it due to the way the Date is reconstructed? A Date in Pharo is a 24 hour period and thus the timezone is important, e.g. the start of 23 Jun in London is not the same as 23 Jun in Melbourne. If you want to compare the date using day / month / year and not as a 24 hour period, try using #equals: instead of #=. HTH, Alistair |
Re: Strange Result - OmniBase bug or Date feature?
|
Administrator
|
Peter Kenny wrote
> luckily I did not have anything major planned for the weekend! Or else I > should just follow Todd's advice. Glad you had a boring weekend planned - it seems we all will benefit ;-) Keep going and asking questions! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Cheers,
Sean |
| Free forum by Nabble | Edit this page |