Strange Result - OmniBase bug or Date feature?

On 23 Jun 2018, at 18:09, PBKResearch <[hidden email]> wrote:

Retransmit with additional information: All tests with Windows 10 with all recent updates

 

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

On 24 Jun 2018, at 10:02, Esteban Lorenzano <[hidden email]> wrote:

On 23 Jun 2018, at 18:09, PBKResearch <[hidden email]> wrote:

Retransmit with additional information: All tests with Windows 10 with all recent updates

 

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

no idea about it but… feel free to send me a PR (and I will move the port to pharo-nosql group as is not “my” project) :)

cheers!

Esteban

 

Peter Kenny