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