[csillag]

If you want a field that expresses a date without a type, make the field type "date" not "datetime".

If I have an SQL column defined as DateTime SQL type, and I override the default "datetime" smartgwt type as "date", will this cause any problems?

(I am trying to avoid timezone conversion problems, so I would like to get rid of the time.)

[Isomorphic]

So long as the time stored in the database is always zero seconds after midnight in server local time, this is fine. Otherwise, you will want to either normalize all your data to the server timezone, normalize the server timezone to the data, or write server-side code for conversion.

[csillag]

So long as the time stored in the database is always zero seconds after midnight in server local time, this is fine.

All the data in the DB is written via the SGWT DSs.
If I declare the field as "date", will this guarantee that all times will be zero seconds after midnight?

And what happens when DST kicks in and out? Does this screw up the values stored before the change?

[Isomorphic]

Yes, SGWT DataSources will write the value in zero seconds past midnight local time.

Since a given day is either in DST or not in DST, it will remain the same date when read again from the database, regardless of whether the server's timezone currently puts it in DST.

[csillag]

Short version:

Where can I find an overview about the various settings influencing date interpretation (in DB, server side, client side), and the common pitfalls of the whole mess?

Long version:

I store date values on the server, in a MySQL db, in a DATETIME column. (I am not using date, because it's missing in Oracle and MSSQL).
I only write zero time data to the db.
The DB stores everything in server local time.

On the client, if I display the data in a DataBound component, it's ok. (Date is same as in DB.)
If I read out the date as a string, using record.getAttribute("whatever"), it's OK (Date is same as in DB):

Tue Jan 01 2008 00:00:00 GMT+0100 (CET)

It's important to note the the offset is not constant because of DST.

If I read out the date as a Date object, using record.getAttributeAsDate("whatever"), the resulting Date object is converted to a different timezone (UTC), and thus it's off:

Mon Dec 31 23:00:00 GMT 2007

How do I avoid this? I would like to have the date exactly as it is stored on the server, without any timezone correction (that's why I am switching to date from datetime in the first place), but the result is still off. Technically, this is not wrong, since the actual timestamp values are equal, because both contain the offset. But the UTC version is still useless for me, because I get the data out from the Date object using getYear(), getMonth() and similar methods, and these yield wrong (UTC) results.

I am aware that these are obsolete methods, but Calendar is not available on the client side. Is there a better way to do this?

[csillag]

For now, I have started to parse the timezone offset string out of the string value of the field, and correct the date with that.
This way, I have UTC dates with the same numeric values as the original server local times.

This seems to work for now, but it feels wrong, so I would like to solve this properly. Any idea?

[csillag]

up

Could you please take a look at this?

[Isomorphic]

If you want a cleaner solution, you might try asking on the GWT forums, since this is fundamentally a problem with needing a replacement for Calendar to get local times without calling deprecated APIs.

One other option is to use the JavaScript Date object, which when created with a timestamp then responds to getHours() et al in browser-local time.

[csillag]

I can live with deprecated APIs for now.

The problem (which suggests that I am doing something fundamentally wrong) is that I need to manually offset the date in order to get access to the data in the wanted time zone.

Since I want server local time everywhere, I am 99% sure that this can be doing something this ugly.