Date Index -
Author Index -
Subject Index -
Thread Index -
Re: Hdb and Tdb behave differently on the same machine about timezone
- Date: Fri, 16 Oct 2009 15:01:15 +0200
- From: Giacomo <Hidden Address>
- Subject: Re: Hdb and Tdb behave differently on the same machine about timezone
On Friday 16 October 2009 14:39:40 PIERRE-JOSEPH Sandra wrote:
> Hi Giacomo,
Hi Sandra!
Thanks.
> I'm sorry Giacomo, I have look on the code and the behaviour is the same
> for TDB and HDB, we use a java.sql.Timestamp object in the two cases. You
> are right for HDB:
> - In the HdbAttributeInsert.java class the received timestamp value is
> converted in a TimeStamp object before to be inserted in the DB. Timestamp
> _timeSt = new Timestamp(scalarEvent.getTimeStamp());
> For TDB:
> - In the FileTools.java the received timestamp is also converted in a
> TimeStamp object. In the processEventScalar method we use:
> toDbTimeStringMySQL(scalarEvent.getTimeStamp()). This last method works
> with the Timestamp object too.
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.
>
> 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.
>