A lateral thought - is there a reason the column is declared as TIMESTAMP
instead of DATE?
> On 30 Mar 2016, at 2:50 PM, g kuczera <gkucz...@gmail.com> wrote:
>
> 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?
>>>>>>
>>>>>
>>>>
>>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
