[Pharo-users] Strange Result - OmniBase bug or Date feature?

PBKResearch peter at pbkresearch.co.uk
Sat Jun 23 11:46:59 EDT 2018


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20180623/6645d776/attachment-0001.html>


More information about the Pharo-users mailing list