2

In a web application the user can choose the timezone which is passed to the timezone attribute of the calendar widget:

<p:calendar value="#{curValue}" timeZone="#{settingsBL.getTimeZoneIdSet()}" />

The delivered date in the backing bean is converted to the timezone of the server (JBoss in my case with CEST). The backend want the date and time as always as UTC (and delivers it in UTC). So when I store a date I have to convert the CEST date to UTC and save it. If a date is delivered from backend it is UTC. I have to convert it to the system default (JBoss with CEST) and the calendar will take care that it is displayed correctly on the client. Is this correct? I am a little bit confused about that. The server timezone is variable and cannot be set hard to UTC or something. The date from the client is always converted to CEST for my example. Regardless what I set to javax.faces.DATETIMECONVERTER_DEFAULT_TIMEZONE_IS_SYSTEM_TIMEZONE in web.xml.

I am using primefaces 5.2.13 and Mojarra 2.2.12 with JBoss 6.4

opfau
  • 731
  • 9
  • 37

1 Answers1

2

The timeZone attribute of any java.util.Date based JSF component which allows manipulating the time part must be set to the one as expected by the view (frontend). It will be used when converting the java.util.Date instance from the model (backend) to the String representation which will be embedded in generated HTML output. It will also be used when converting the incoming String request parameter value to a concrete java.util.Date instance which will be used in the model. If you don't allow manipulating the time part, then just stick to the default of timeZone="GMT".

And now comes the key: the java.util.Date does not hold any timezone information. It's internally always GMT. JSF knows that. JDBC knows that. JPA knows that. As long as you tell JSF what timezone the view uses, and you tell JDBC/JPA what timezone the DB uses, then all should be well.

Perhaps your confusion is caused because you did something like System.out.println(date) to verify one and other. Its toString() result will internally use TimeZone#getDefault() and thus not explicitly use GMT/UTC during the String generation. You'll then confusingly see the date in the system default timezone being printed. To print the date with GMT timezone (in order to debug/log/verify it and such), do so:

System.out.println(DateTimeFormatter.ISO_DATE_TIME.format(date.toInstant().atZone(ZoneId.of("GMT"))));
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • Correct. In my case the date is stored in the database without any timezone. It is set by convention that UTC is stored and when it is read it is also UTC. So maybe I don't have a problem here? In my case when I choose the 1st of a month in a search mask and submit, the value is the last day of the month before. – opfau Oct 09 '15 at 13:15
  • That will indeed happen if view doesn't use GMT/UTC timezone but a timezone somewhere in the GMT+x. Explanation here: http://stackoverflow.com/questions/12351244/jsf-convertdatetime-renders-the-previous-day There should be no problem if you save time along it as well and it is presented back to view from DB. Or better, just always explicitly specify `timeZone="GMT"` in components where you need to present/accept/select only dates (without time). Without time, you're not interested in **time** zone, right? – BalusC Oct 09 '15 at 13:17
  • It is a search with a from-value and a to-value. So the from-value's time is set to 00:00:00 and the to-value's to 23:59:59. So the user chooses only a date but time is important anyway. But for the example of the search field a hard set timezone to UTC should be ok I think. The problem of the changed day after submit comes from the conversion from UTC to CEST and back then. I haven't got the problem...I am confused. Time for another debug session. – opfau Oct 09 '15 at 13:25
  • Regardless of the time, if you need a fixed time regardless of the time zone, set JSF component's time zone to GMT/UTC. – BalusC Oct 09 '15 at 13:26
  • Yes for a search field I think this is correct. But I have also a date in a edit field. So the date must be stored as UTC and displayed for editing in the chosen timezone. I don't have a time here also, but cannot set a hard timezone. – opfau Oct 09 '15 at 13:30
  • Configure two timezones. "Server timezone" and "Client timezone". Pick "Server timezone" where time is not manipulable by client (i.e. predefined by server/webapp). Pick "Client timezone" where time is manipulable by client. – BalusC Oct 09 '15 at 13:32
  • Is it possible to set the timezone hard for a web application? So that it would be alwys UTC for instance in the backing beans. – opfau Oct 09 '15 at 13:54
  • 1
    That's the default already (when you don't specify `timeZone` nor that context param). See also link in my 1st comment here above. – BalusC Oct 09 '15 at 13:56
  • Off topic but a pifall: eclipse shows a date in the IDE timezone on debuging ;) – opfau Oct 09 '15 at 14:09