Hi,
As I said before, I am pretty sure that your problem is not Tapestry
related, but caused by mismatches in timezone interpretation between values
stored by Postgres and JDBC. I will try to help, but for more information
check more general resources regarding Postgress, JDBC and date/time
handling in Java.
Your Birthdate field is declared 'timestamp without timezone' in Postgress,
so it tells the client code to interpret the value in its local timezone
(whatever it is set). As during summer time in Central European Time 23:00
is equal to midnight in UT,C it explains the mismatch. Also, please
remember that the values stored in Postgress database (for 'timestamp'
type) are not really year-month-day, but actually seconds from some
predetermined moment (epoch). The difference between 'timestamp with time
zone' and 'timestamp without time zone' types in Postgress is how it
handles input and output values. 'With time zone' type normalises input
values to UTC and output values are in UTC, 'without time zone' ignores any
time zone information on input values and tells a client to interpret
output values in whatever timezone it wants. I strongly recommend avoiding
'timestamp without time zone' type, as it causes problems exactly like you
are observing.
Only confusing thing in your information is that sometimes you get the date
you want, and sometimes not. Are you sure that they come from the same
record? If they are from the same record, my guess is that there are calsl
to TimeZone.setDefault() in your code, probably added as crude attempts to
"fix" timezone problems. You can try using
"Calendar.getInstance(TimeZone.getTimeZone("GMT"), Locale.ROOT);" instead
of Calendar.getInstance() to avoid problems with default settings.
Best regards,
Cezary
On Wed, Mar 30, 2016 at 9:30 AM, JumpStart <
geoff.callender.jumpst...@gmail.com> wrote:
> 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
>
>
