The same thread really reads the same value from the database every few
seconds and it may come out different? I don't buy it, there must be
something else going on at the same time. Are you sure it's the same value?
Is there something else writing to it at the same time? Can the system
default timezone change (perhaps also print out TimeZone.getDefault(), Date
initialized to the default timezone). I'd still suspect some type of
timezone issue.
Kalle
On Tue, Mar 29, 2016 at 3:39 PM, g kuczera <gkucz...@gmail.com> wrote:
> Hi guys,
> First of all, thanks for the answer and the effort you put into writing
> them.
>
> I checked few things and read couple of articles about similar problems and
> here is my little summary:
>
> - my PostgreSQL birthDate column's type is 'birthDate TIMESTAMP WITHOUT
> TIME ZONE'
> - the values contained by the column do not have the time part, the
> year-month-day is used, eg. 1982-03-28
> - then the user Entity has the birth date field with annotations
>
> @Column(name = "birthDate ")
>
> @Temporal(TemporalType.DATE)
>
> private java.util.Date birthDate;
>
>
> - the call calendar.getTimeZone().getDisplayName() returns
>
> The Calendar instance is created in this way:
>
> Calendar calendar = Calendar.getInstance();
> calendar.setTime(user.getBirthDate());
>
>
> So the TIMESTAMP value from the database is interpreted as the
> java.util.Date, what is achieved by putting the Temporal annotation. Then,
> when I call the getter (getBirthDate method) the "truncated" TIMESTAMP is
> returned.
>
> But still, after fetching the birthDate for 4 times, the fifth one becomes
> corrupted:
>
> 30-03-16 00:25:36:746 - {INFO} profil.ProfilEdition Thread
> [qtp1357767732-54]; birth date equals (setupRender - getting from raw
> query): 1982-03-28 00:00:00.0, 1982-03-28 00:00:00.0
> 30-03-16 00:25:44:497 - {INFO} profil.ProfilEdition Thread
> [qtp1357767732-65]; birth date equals (setupRender - getting from raw
> query): 1982-03-28 00:00:00.0, 1982-03-28 00:00:00.0
> 30-03-16 00:25:46:037 - {INFO} profil.ProfilEdition Thread
> [qtp1357767732-60]; birth date equals (setupRender - getting from raw
> query): 1982-03-28 00:00:00.0, 1982-03-28 00:00:00.0
> 30-03-16 00:25:46:884 - {INFO} profil.ProfilEdition Thread
> [qtp1357767732-62]; birth date equals (setupRender - getting from raw
> query): 1982-03-28 00:00:00.0, 1982-03-28 00:00:00.0
> 30-03-16 00:25:48:843 - {INFO} profil.ProfilEdition Thread
> [qtp1357767732-63]; birth date equals (setupRender - getting from raw
> query): 1982-03-27 23:00:00.0, 1982-03-27 23:00:00.0
>
> The log comes from casting the raw query result to java.sql.Timestamp. The
> value after comma is the same one, but casted to java.util.Date (these are
> results of toString method)..
>
> I will continue to investigate the thing tomorrow.
>
> 2016-03-24 15:47 GMT+01:00 Cezary Biernacki <cezary...@gmail.com>:
>
> > Hi,
> > I doubt it is a Tapestry related problem. I have seen similar issues, and
> > they are generally caused by time zone translations. My guess is that
> your
> > database stores date birth as a timestamp (i.e. including specific hours
> > and minutes) in some specific time zone, and your Java code retrieving
> > timestamps translates it to a different time zone. To diagnose, you
> should
> > check what is actually stored in the database, what kind of data type is
> > used to store date of birth (database engines often have many options to
> > store dates and timestamps including or not time zones), what Java type
> is
> > returned by user.getBirthDate() and what is the actual returned value
> > (exact content, not result of toString()), and what assumptions about
> using
> > time zones your JDBC driver is making. Typically problems arise when some
> > parts of the systems treat time stamps as set in UTC and others apply
> user
> > (client) default time zone. To fix this, one should have methodically
> > ensure that all parts are using consistent time zone policy, and any time
> > zone translations occur only when necessary.
> >
> > Best regards,
> > Cezary
> >
> >
> > On Tue, Mar 22, 2016 at 8:55 PM, g kuczera <gkucz...@gmail.com> wrote:
> >
> > > Hi guys,
> > > I do not really know if it is connected with tapestry or only the
> > > Hibernate, but maybe that is the case. So there is a embedded calendar
> on
> > > the site, the one from tapestry-jquery library:
> > > http://tapestry5-jquery.com/mixins/docscustomdatepicker
> > >
> > > If the user chose - during registration - the 28/03/1982 date, the
> value
> > > will be correctly save to the database. But if you want to change this
> > date
> > > and the calendar is going to be prepared, the date retrieved by the
> > UserDao
> > > (the birthDate field) equals to 27/03/1982.
> > >
> > > I use the DAOs layer, which uses the Hibernate session. It is
> > automatically
> > > passed as an argument during the binding process (in the AppModule
> > class):
> > >
> > > binder.bind(UserDao.class,
> > > UserDaoImpl.class).scope(ScopeConstants.PERTHREAD);
> > >
> > > The UserDao is used in setupRender and onActivate methods of my page
> > (user
> > > is an javax Entity):
> > >
> > > user = userDao.load(userId);
> > > user.getBirthDate().toString()
> > >
> > > What's funny, if I use the Hibernate in the different way
> > >
> > > List<Object> birthDatesList =
> userDao.getSession().createSQLQuery("select
> > > birthdate from user where id = " + userId).list();
> > > java.sql.Timestamp birthDate =
> > (java.sql.Timestamp)(birthDatesList.get(0));
> > > log.info("setupRender (birth date): " + birthDate.toString());
> > >
> > > the returned date is correct.
> > >
> > > I also logged the birth dates of the other users, and the problem
> occurs
> > > only in the 28/03/1982 case. Have you ever noticed anything like that?
> > >
> >
>
