I also checked if the changing temporal annotation to "TIMESTAMP" affects
this situation in any way. But there is no change - the fetched data still
appears to be 1982-03-27 23:00:00 after refreshing by ctrl + r for few
times.
Ok, I got it - truncating the date does not change it after all, it only
get rid of the time part.
2016-03-30 17:31 GMT+02:00 g kuczera <gkucz...@gmail.com>:
> 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
>> >
>> >
>>
>
>
