RE : RE : Hdb and Tdb behave differently on the same machine about timezone

["PIERRE-JOSEPH Sandra" <Hidden Address>]

Giacomo, I thought to something, there is a difference between the two archiving systems at Elettra. 

At Soleil, as at Alba, we use the HDB and TDB archiving systems in polling mode. Your TDB archiving system is also in polling mode and it woks well.  Your problem is only with the HDB archiving system and this one works in events mode. Maybe a timestamp conversion is done in the classes which are in charge of managing this mode.

The polling mode is based on ATKCore classes. We use the Refrecher class in which a thread is running. Inside it a read attribute command is sent to the hosted device. The read command is the same which is used by the ATKPanel and the Test Device. The timestamp, provided by the device, arrives with the attribute value. 

I don't know how it works in events mode. Maybe you could have a look on this part.

Ciao,

Sandra

Hi Giacomo
>>Could this be the issue? In TDB, which in our case saves data correctly,
>>you
>>call toDbTimeStringMySQL() which perhaps converts the unix timestamp (UTC)
>>in
>>localtime.
>>On the other hand, in HDB you construct a java Timestamp with the unix UTC
>>timestamp taken from the device attribute timestamp.
>>
>>Maybe when you `insert' the date time into the MySQL database, this makes
>>the
>>difference, toDbTimeStringMySQL() probably converting date/time into
>>localtime.
>>Simple Timestamp instead does not convert UTC to localtime and saves
>>uncorrectly.

[PIERRE JOSEPH ZEPHIR Sandra]
It is the same code:
In HDB:
Timestamp _timeSt = new Timestamp(scalarEvent.getTimeStamp());
preparedStatement.setTimestamp(1 , _timeSt);
In TDB:
....
toDbTimeStringMySQL(scalarEvent.getTimeStamp());
....
private String toDbTimeStringMySQL(long time){
        return ( new Timestamp(time) ).toString();}

I don't know what to say, according to the code it is the same behaviour for HDB than TDB.
To understand what is happening it could be interesting to add a output trace, first just after the preparedStatement.setTimestamp(1 , _timeSt); line. And start the HdbArchiver in a test platform with a modified API. You can download the code from CVS and produce your own api jar file.

I haven't another solution for the moment. Maybe Sergi will have one other?

Bye bye
Sandra

>>> At the beginning the timestamp comes in the
>>>  fr.esrf.tangoatk.core.NumberScalarEvent container in a long type (see
>>for
>>>  instance the HdbArchiver.Collector.scalar.numberScalarChange method).
>>The
>>>  NumberScalarEvent is converted in a
>>>  fr.soleil.hdbtdbArchivingApi.ArchivingTools.Tools.ScalarEvent where the
>>>  timestamp is also a long. There is no treatment in the archiving code
>>on
>>>  the timestamp value.
>>>
>>> Have you verified which is the time of the unix server machine on which
>>the
>>>  device who hosts the attribute is running? Maybe this machine is not
>>>  synchronized.
>>
>>The machine has correct timestamp, in UTC.
>>
>>>  This behaviour is it true for all the TDB data?
>>
>>TDB saves correctly converted into localtime, as I underlined above.
>>
>>>  Is it a new
>>>  behaviour? Have you looked also the TDB generated files to see if the
>>>  timestamps are correct or not?
>>
>>The .dat text files are correctly generated (TDB saves correctly )
>>
>>>  The TDB and HDB DB have been created with
>>>  sgad in a same way?
>>> Otherwise, you can try to modify the code in a branch and tested it.
>>
>>Well, that's all!
>>
>>Thanks for any hint.
>>
>>Giacomo
>>
>>>
>>> Bye
>>> Sandra
>>>
>>> >>-----Message d'origine-----
>>> >>De : Giacomo [mailto:Hidden Address
>>> >>Envoyé : mercredi 14 octobre 2009 12:20
>>> >>À : Hidden Address
>>> >>Cc : PIERRE-JOSEPH Sandra; Hidden Address;
>>> >>Hidden Address
>>> >>Objet : Re: Hdb and Tdb behave differently on the same machine about
>>> >>timezone
>>> >>
>>> >>On Wednesday 30 September 2009 09:34:56 PIERRE-JOSEPH Sandra wrote:
>>> >>> Hi Giacomo,
>>> >>
>>> >>Hi Sandra!
>>> >>Thanks for your answer!
>>> >>
>>> >>> The timestamps saved in the databases, for HDB as well as TDB, is
>>given
>>> >>
>>> >>by
>>> >>
>>> >>>  the device who hosts the archived attribute. No treatment is
>>applied
>>> >>> on the timestamp by the archivers, and so the collectors.
>>> >>
>>> >>Yes I see. But, at least in the CVS version, HdbAttributeInsert.java:
>>> >>
>>> >>Timestamp _timeSt = new Timestamp(scalarEvent.getTimeStamp());
>>> >>preparedStatement.setTimestamp(1 , _timeSt);
>>> >>
>>> >>the code creates a java Timestamp Object. Might this lead to timezone
>>> >>representation problems?
>>> >>We should investigate on  this point.
>>> >>
>>> >>Correct me if I am wrong or if something has changed between the
>>latest
>>> >>version (I think the one I am looking at) and the previous 1.4.
>>> >>
>>> >>Thanks in advance.
>>> >>
>>> >>Giacomo
>>> >>
>>> >>> This problem appears for all the attributes stored in the TDB
>>tables?
>>> >>> You can compare the attributes tables description in both databases.
>>> >>> Maybe, have a look on the timestamp value provided by a read
>>attribute
>>> >>
>>> >>on
>>> >>
>>> >>>  the device directly.
>>> >>>
>>> >>> Is this problem already appeared with your DB, Sergi?
>>> >>>
>>> >>> I hope its help!
>>> >>> Sandra
>>> >>>
>>> >>> >>-----Message d'origine-----
>>> >>> >>De : Giacomo [mailto:Hidden Address
>>> >>> >>Envoyé : lundi 21 septembre 2009 15:35
>>> >>> >>À : PIERRE-JOSEPH Sandra
>>> >>> >>Cc : Hidden Address; Hidden Address
>>> >>> >>Objet : Hdb and Tdb behave differently on the same machine about
>>> >>
>>> >>timezone
>>> >>
>>> >>> >>Hi to all.
>>> >>> >>
>>> >>> >>Our recent hdb and tdb installations revealed a strange issue:
>>> >>> >>
>>> >>> >>we found timestamps in local time in data stored in tdb tables,
>>while
>>> >>
>>> >>in
>>> >>
>>> >>> >>hdb
>>> >>> >>tables the timestamps are expressed in UTC, both running on the
>>same
>>> >>> >>machine.
>>> >>> >>
>>> >>> >>We do not know whether this problem is dued to our specific
>>> >>
>>> >>installation
>>> >>
>>> >>> >>or
>>> >>> >>whether it may depend on internal device server behaviour.
>>> >>> >>The data collectors should be the same in both devices, shouldn't
>>> >>> >> they (they
>>> >>> >>both inherit from common collector classes)?
>>> >>> >>
>>> >>> >>Thanks in advance for any hint.
>>> >>> >>
>>> >>> >>Giacomo Strangolino, Elettra.
>>>