Hi again, guys.
I grepped for the TimeZone in the project directory, but there is nothing
interesting there (at least for me).
If I use
Calendar.getInstance(TimeZone.getTimeZone("GMT"), Locale.ROOT);
to get the calendar, the resulting log looks like this:
30-03-16 16:59:42:797 - {INFO} profil.ProfilEdition Thread
[qtp1357767732-92]; ****
30-03-16 16:59:42:804 - {INFO} profil.ProfilEdition Thread
[qtp1357767732-92]; birth date equals (setupRender - getting from dao):
1982-03-28
30-03-16 16:59:42:805 - {INFO} profil.ProfilEdition Thread
[qtp1357767732-92]; 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 16:59:42:805 - {INFO} profil.ProfilEdition Thread
[qtp1357767732-92]; birth date time equals (setupRender): 386118000000
30-03-16 16:59:42:805 - {INFO} profil.ProfilEdition Thread
[qtp1357767732-92]; birth date equals (setupRender - getting from dao by
the calendar): 1982, 2, 27, 23:0:0 (day of week: 7, time zone: Greenwich
Mean Time, dst offset: 0)
30-03-16 16:59:49:500 - {INFO} profil.ProfilEdition Thread
[qtp1357767732-72]; ****
30-03-16 16:59:49:500 - {INFO} profil.ProfilEdition Thread
[qtp1357767732-72]; birth date equals (setupRender - getting from dao):
1982-03-28
30-03-16 16:59:49:501 - {INFO} profil.ProfilEdition Thread
[qtp1357767732-72]; 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 16:59:49:502 - {INFO} profil.ProfilEdition Thread
[qtp1357767732-72]; birth date time equals (setupRender): 386118000000
30-03-16 16:59:49:502 - {INFO} profil.ProfilEdition Thread
[qtp1357767732-72]; birth date equals (setupRender - getting from dao by
the calendar): 1982, 2, 27, 23:0:0 (day of week: 7, time zone: Greenwich
Mean Time, dst offset: 0)
30-03-16 16:59:53:771 - {INFO} profil.ProfilEdition Thread
[qtp1357767732-95]; ****
30-03-16 16:59:53:772 - {INFO} profil.ProfilEdition Thread
[qtp1357767732-95]; birth date equals (setupRender - getting from dao):
1982-03-27
30-03-16 16:59:53:773 - {INFO} profil.ProfilEdition Thread
[qtp1357767732-95]; 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 16:59:53:773 - {INFO} profil.ProfilEdition Thread
[qtp1357767732-95]; birth date time equals (setupRender): 386031600000
30-03-16 16:59:53:773 - {INFO} profil.ProfilEdition Thread
[qtp1357767732-95]; birth date equals (setupRender - getting from dao by
the calendar): 1982, 2, 26, 23:0:0 (day of week: 6, time zone: Greenwich
Mean Time, dst offset: 0)
30-03-16 16:59:55:067 - {INFO} profil.ProfilEdition Thread
[qtp1357767732-72]; ****
30-03-16 16:59:55:067 - {INFO} profil.ProfilEdition Thread
[qtp1357767732-72]; birth date equals (setupRender - getting from dao):
1982-03-27
30-03-16 16:59:55:069 - {INFO} profil.ProfilEdition Thread
[qtp1357767732-72]; birth date equals (setupRender - getting from raw
query): 1982-03-27 23:00:00.0, 1982-03-27 23:00:00.0
30-03-16 16:59:55:069 - {INFO} profil.ProfilEdition Thread
[qtp1357767732-72]; birth date time equals (setupRender): 386031600000
30-03-16 16:59:55:069 - {INFO} profil.ProfilEdition Thread
[qtp1357767732-72]; birth date equals (setupRender - getting from dao by
the calendar): 1982, 2, 26, 23:0:0 (day of week: 6, time zone: Greenwich
Mean Time, dst offset: 0)
The "birth date time equals" log is the result of
"Long.toString(user.getBirthDate().getTime())" call.
I also changed the column type to TIMESTAMPTZ. Then the logs looks fine:
http://pastebin.com/hXvdp2n1
2016-03-30 10:54 GMT+02:00 Cezary Biernacki <cezary...@gmail.com>:
> 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
> >
> >
>
