I also checked the default PostgreSQL timezone (in the postgresql.conf
file), which is set to "Poland".
2016-03-30 8:47 GMT+02:00 g kuczera <gkucz...@gmail.com>:
> 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?
>> > > >
>> > >
>> >
>>
>
>
