2

I have a database column of type date with the following value

2014-05-01

I then have the following hibernate mapping:

@Temporal(TemporalType.DATE)
@Column(name = "end_date", nullable = false, length = 13)
public Date getEndDate() {
    return this.endDate;
}

public void setEndDate(Date endDate) {
    this.endDate = endDate;
}

When I reference this date in a JSF page in the following way

<h:outputText value="#{someBean.endDate}">
    <f:convertDateTime pattern="d MMM yyyy" />
</h:outputText>

It reads as 

'30 Apr 2014'

So I remove the f:convertDateTime and it shows: 

'5/1/2014'

So I then change the f:convertDateTime to:

<h:outputText value="#{someBean.endDate}">
    <f:convertDateTime pattern="HH:mm d MMM yyyy" />
</h:outputText>

And it reads: 

'23:00 30 Apr 2014'

So my guess is that my computer is set to BST (British Summer Time) and the date in the database is somehow set to GMT (or Zulu time) so that the -1 hour causes the date to move back in time to the previous day?

Is there any way to stop this happening, I just want to treat it as a date, with no time component!

DaveB
  • 2,953
  • 7
  • 38
  • 60
  • possible duplicate of [f:convertDateTime displays wrong Date](http://stackoverflow.com/questions/2689245/fconvertdatetime-displays-wrong-date) – Meno Hochschild Apr 04 '14 at 17:19

1 Answers1

2

You should specify the timezone, too (and also the english locale for safety):

<h:outputText value="#{someBean.endDate}">
    <f:convertDateTime pattern="d MMM yyyy" timeZone="GMT" locale="en" />
</h:outputText>

Hereby I assume that the input is in UTC-timezone (that is the literal date was originally stored relative to UTC), so using the same offset for output format will not change the date (and your intermedium output of "5/1/2014" was just the default US-format changed by the same offset effect).

If you have stored your date using another timezone conversion then you have to adjust the timeZone-attribute (for example "Europe/London").

UPDATE: I have found this SO-question which should help you, too.

Community
  • 1
  • 1
Meno Hochschild
  • 42,708
  • 7
  • 104
  • 126
  • Great, yes that worked. But can you tell me, if the date is stored in the database as '01/05/2014' how does it know what timezone it was inputed in? – DaveB Apr 04 '14 at 17:20
  • 1
    @DaveB An object of type `java.util.Date` itself has no timezone in its internal state. But the transfer from application layer via jdbc layer to database uses timezone conversion and can therefore change the stored milliseconds relative to UNIX epoch. – Meno Hochschild Apr 04 '14 at 17:22
  • Thank you, yes that makes sense, also the linked question helped me out too – DaveB Apr 04 '14 at 19:49
  • @MenoHochschild No, the input was not in UTC. The data type of the Postgres column was `DATE`. A [Postgres `DATE`](http://www.postgresql.org/docs/current/static/datatype-datetime.html) represents **only a date** (year, month, day-of-month) **without a time portion**, per the [SQL-92 spec](http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt). The core problem here is retrieving date-only from the database, and then used to create a java.util.Date object which includes a time-of-day along with the date. A time portion is created in the process, presumably 00:00:00 for a time zone (UTC?). – Basil Bourque Apr 05 '14 at 04:45
  • @BasilBourque Yes, something like that. By the way, Postgre-SQL shows better standard-conform behaviour than Oracle. – Meno Hochschild Apr 05 '14 at 05:27
  • Yes, [PostgreSQL](http://www.postgresql.org/) is one of the most SQL standard compliant products on the market. For that reason, their [excellent documentation](http://www.postgresql.org/docs/) proves quite useful even if you use some other database system. Ironic given that the Postgres team has never been a member of the standards committee (afaik). – Basil Bourque Apr 05 '14 at 07:11