I finally figured it out. -The Operating System's timezone DOES NOT matter -The Database's timezone DOES NOT matter. -The JVM has it's own timezone and this is the only one that matters! Since the running JVM does a "new Date(long)" before inserting into the database that is where the Date manipulation occurred. You can think of the insert into the database as a .toString on the Date object...and since my JVM was set to GMT that is why I saw values 7 hours in the future in the db. You can see how the data itself has no integrity because it depends on the timezone of the reader!
Full account of what happens: 1) Client creates a java.util.Date 2) When sending over RPC it calls com.google.gwt.user.client.rpc.core.java.util.Date_CustomFieldSerializer#serialize which just writes the .getTime() long value to a stream. That long value would be the same even if it were created on another machine in a differennt timezone (the milliseconds since epoch is the same value). 3) When it arrives at the server, the server calls com.google.gwt.user.client.rpc.core.java.util.Date_CustomFieldSerializer#instantiate which does a "new Date(long)". Now since the JVM on the server is in a different timezone it's Date String will look different then the Date's String on the client. "09:30" in MST is "16:30" in GMT. 4) That Date object is then written to the database, basically calling .toString(). [THIS is where you lose data integrity*] In my case the JVM was set to GMT so the Date in the database will be 7 hours different then what I see in the client. Because the data has no integrity you have to be damned sure the reader is in the same timezone as the writer. *Note so long as the JVMs timezone stays the same, writing and reading from the database won't corrupt the data...because that string<=>long translation will stay the same. FIX: To ensure my timezone doesn't change I added this JVM parameter to my application server: "-Duser.timezone=MST". I think that is sufficient while I'm still not sure how to set it at the entire JVM level. On Apr 6, 10:34 am, javaunixsolaris <[email protected]> wrote: > I noticed DATETIME doesn't preserve the timezone...losing data > integrity. I know this isn't a SQL forum but when I select on the > TIMESTAMP will it be human readable like "2011-01-01 10:30:00"? If > that's the case I should prefer TIMESTAMP over DATETIME for it's Data > Integrity. (Hibernate is creating the SQL types for me so this might > still be hard to implement) > > On Apr 5, 10:38 pm, kozura <[email protected]> wrote: > > > Hmm interesting. Well there certainly is a difference in the Java > > Date class you get using Dev mode and the JS Date class you'd see in > > production - I've seen discrepancies in some of my work that were > > confounding til I realized that the different implementations was the > > issue. I'm not sure if that necessarily translates into a difference > > in how they are serialized and transmitted. But with something like > > firebug it'd be pretty easy to look at the RPC packet transmitted in > > dev vs production mode. > > > That said, I think your production mode is doing the correct thing. > > If you're using DATETIME in mysql then it has no idea of timezone, > > it's just a year/month/day/h/m/s storage (vs TIMESTAMP which is msec > > since 1970). So the most transparent to handle it correctly is to > > transmit and store it in a "standard" known timezone, eg UTC with no > > DST, and input/display on the client side based on the particular > > timezone there, which is what appears to happen with your production > > mode. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
