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

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

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.
>>>