I have an application that runs in The Netherlands, but is operated from England. Date/times are thus stored and converted with a dateformatter set with the Timezone "Europe/London". It looks fine. Ie, from a JSP with an input form, I enter a time as "15:00" (text, UK time) and in the database it shows "16:00" (Dutch time, after using dateformatter and timezone) which is expected. Reading and displaying it back also works, EXCEPT when I use JSTL and <fmt:formatDate timeZone="Europe/London" ... When daylight savings kick in (start of April I think), the times are showed 1 our behind when displaying it with JSTL. When formatting it manually with my dateformatter, it is correct again. Ie, I enter a time as "15:00", it shows in the DB as "16:00", but JSTL shows it as "14:00". Formatting 'manually' shows the correct 15:00 time. Is this a bug? Or is there something else I need to do to get this right? Thanks
Btw, I use JSTL 1.0.5, latest version thus.
Riaan, Could you provide us with a simple test case to reproduce the problem. I got lost somewhere between 14:00, 15:00, and 16:00 :-).
Apologies: <fmt:formatDate value="${row.TIME}" timeZone="<%= Constants.TIMEZONE %>" pattern="dd-MM-yyyy 'at' HH:mm"/> does not work <fmt:formatDate value="${row.TIME}" timeZone="Europe/London" pattern="dd-MM-yyyy 'at' HH:mm"/> does. ( Constants.TIMEZONE = "Europe/London") Someone commented: > So the java scriplet <%= xxx %> is not allowed? It depends. If you're on a JSP 2.0 container (JSTL 1.1), then this works. It won't on a JSP 1.2 container (JSTL 1.0). In JSTL 1.0, you need to use the RT libraries to use rtexprvalues. See the spec for details.
Riaan, We need a more complete test, like a page that sets the date object using scriplet code and then display the results using JSTL. For instance, you said that you enter the time from a JSP page, save it in the database and then display using JSTL. If you could write a simple version of this process, like a jsp page that writes to memory (instead of database) and another that reads the same memory but displaying the wrong data, we could reproduce it and isolate the bug. Felipe OOPS: nevermind, just now I realized you mark this bug as invalid...