29

A date (as the Date temporal type) is stored in my DB like this: 31.10.2012
When I display it in the UI, it is rendered like this per default: 2012-10-31
I convert it using <f:convertDateTime pattern="dd.MM.yyyy" /> and unexpectedly it turns to
30.10.2012

The SimpleDateconverter, fed with the same date and the same format string returns 31.10.2012, as expected.

What am I missing?

Thank you

EDIT : for dates stored as Timestamp the same conversion yields correct results, so I suppose it has something to do with the Date interpreted as the exact midnight which in turn might be interpreted to belong to 2 different days. But I still have no clue where to define the behaviour and what would be the best workaround.

kostja
  • 60,521
  • 48
  • 179
  • 224

1 Answers1

82

This is undoubtedly a timezone-related issue.

JSF defaults to GMT (UTC) in date/time conversion. So if your server platform default timezone is GMT+X (not GMT-X), then the time will go back in the past X-amount of hours. If the time is already 00:00:00 (midnight), then the date will even go back one day in the past.

There are 2 standard ways to achieve your functional requirement anyway:

  1. Tell JSF to use the server platform default timezone instead for all date/time conversion by adding the following context parameter to web.xml:

    <context-param>
        <param-name>javax.faces.DATETIMECONVERTER_DEFAULT_TIMEZONE_IS_SYSTEM_TIMEZONE</param-name>
        <param-value>true</param-value>
    </context-param>
    
  2. Alter every <f:convertDateTime> to explicitly specify the webapp-specific timezone. As you're based in Germany and the date format pattern also confirms this, I'll assume CET.

    <f:convertDateTime ... timeZone="CET" />
    

In any case, using a non-universal or even mixed timezone throughout the application is not recommendable. It's recommend to set the timezone in all layers and environments to UTC. Not only in the server and front end tier and presentation layer, but also in the SQL database and back end tier and persistence layer. This way the code is not sensitive to timezone and DST(!) related matters and you can just focus on altering the timezone during presentation only, if necessary.

See also:

Community
  • 1
  • 1
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • both approaches worked, I'll be using the first one. Thank you so much. – kostja Sep 10 '12 at 12:35
  • 3
    You're welcome. Be careful though, it has to be "in sync" with the DB timezone, otherwise you may in the future hit the timezone wall again. – BalusC Sep 10 '12 at 12:35
  • The application is for internal use in german medical insurances, I can be sure that it will never be deployed across timezones :) . BTW thanks for the great resource link – kostja Sep 10 '12 at 12:40
  • Option 1 did not work for me, but option 2 did the job. Thank you very much! – user1323246 Mar 19 '13 at 16:44
  • 1
    @user: option 1 will not work if you're using JSF 1.x, or when the system time zone is actually not been set to the desired time zone. – BalusC Mar 19 '13 at 16:46