I observed that behavior on the production server and then confirmed it on
the test server, which is not accessed by any client, etc. I forgot to
mention that the calendar.getTimeZone().getDisplayName() call returns
"Central European Time".
2016-03-30 3:56 GMT+02:00 Kalle Korhonen <kalle.o.korho...@gmail.com>:
> 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?
> > > >
> > >
> >
>
