Thanks for writing this out, didn't realize the JVM has its own timezone and so that's where the conversion was happening. I guess it doesn't matter what particular timezone you use for the server as long as it's always the same - I personally would probably use GMT vs arbitrarily picking MST, as GMT is the standard for zero time, and probably is the default JVM zone?
As for using TIMESTAMP, yeah its output is human readable, although it is represented in 32 bits (seconds since 1970) so you can get Y2038 problems! You might also consider just passing the client timezone, at least the offset from GMT, and storing that in the server alongside so you can remember how the user entered it. On Apr 6, 10:34 am, javaunixsolaris <[email protected]> wrote: > 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.
