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 <pharo-users-boun...@lists.pharo.org> On Behalf Of Alistair Grant Sent: 23 June 2018 17:15 To: Pharo-Users <pharo-users@lists.pharo.org> Subject: Re: [Pharo-users] Strange Result - OmniBase bug or Date feature? Hi Peter, On Sat, 23 Jun 2018 at 17:47, PBKResearch <pe...@pbkresearch.co.uk> 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
