Thread: postgre 7.3 / JSTL problem

Hi,

I'm using Postgre 7.3.4 with the build 113 JDBC
drivers. I am using JSTL (jakarta implementation,
1.0.6) in a web-app running on Tomcat 4.1.30. When I
start my application (in a ServletContextListener), I
have this statement:

Config.set(event.getServletContext(),
Config.FMT_TIME_ZONE, Constants.TIMEZONE);

Where Constants.TIMEZONE = "Europe/Amsterdam"

The server is on New Zealand time, 12 hours ahead of
Amsterdam time.
I have database timestamp fields which are defined as
"DEFAULT now()".

When I browse the database with an explorer tool, the
timestamp is shown in the New Zealand time, eg "07 Mar
06:00". Local (Amsterdam) time is then 06 Mar 18:00.

However, if I try to display the timestamp with JSTL
<fmt:formatDate value="${row.msgTime}" pattern="dd MMM
HH:mm"/>

the time is shown as 07 Mar 12:00. Ie 6 hours before
NZ time instread of 12 hours later.

Any ideas? A bug in the driver? JSTL settings? The
server? My code? :)

Thanks

Charl Gerber wrote:

> I have database timestamp fields which are defined as
> "DEFAULT now()".

timestamp with timezone or timestamp without timezone?

> Any ideas? A bug in the driver? JSTL settings? The
> server? My code? :)

It's pretty much impossible to say unless you can narrow this down to
some test code that we can try (ideally, code that talks JDBC directly).

-O

I tried not setting a timezone and then doing:

SET TIME ZONE 'Europe/Amsterdam'

In both cases the JSTL <fmt:formatDate did not work. I
might have to try with no timezone settings in the
code.

In the second case, after setting the timezone, it
showed the time 7 hours too early.... hmmm. weird.

--- Oliver Jowett <oliver@opencloud.com> wrote:
> Charl Gerber wrote:
>
> > I have database timestamp fields which are defined
> as
> > "DEFAULT now()".
>
> timestamp with timezone or timestamp without
> timezone?
>
> > Any ideas? A bug in the driver? JSTL settings? The
> > server? My code? :)
>
> It's pretty much impossible to say unless you can
> narrow this down to
> some test code that we can try (ideally, code that
> talks JDBC directly).
>
> -O
>