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 onl
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.Pr
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
handlin
The DATE would make sense, especially that the birth date is chosen from
the calendar (I do not require the user to type their birth time too and do
not store the time in any way). But I got this system as it is, so I do not
really know why the creators defined the column in this way.
2016-03-30 9
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 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 :
>
>
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 :
> 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
> men
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 :
> The same th
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 tim
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 co
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
ti
On Tue, 22 Mar 2016 16:55:46 -0300, g kuczera wrote:
Hi guys,
Hi!
binder.bind(UserDao.class,
UserDaoImpl.class).scope(ScopeConstants.PERTHREAD);
Why is it perthread-scoped? I've never seen a DAO which actually needed
that.
List birthDatesList = userDao.getSession().createSQLQuery("se
11 matches
Mail list logo
