Okay, thought I'd post back my final implementation. Thanks for all that replied with suggestions.
Although conversion of date/times is normally what we want to do in applications, there are times when you don't want that. Our app is one of those. It is imperative that we shows dates and times as of where the student is registered (we build software for schools). This is because each district has their own laws and dates are extremely important when it comes to special education. Unfortunately we all know that for some reason, Adobe decided to make the Date class final and the timezoneoffset read only so we can not simply change the timezone. So what we did was tweak our code generation templates for our communications layer to add date adjustments in the readExternal and writeExternal overwritten functions. Also, at application startup we make a call to the server to get the server timezone offset as well as get the clients timezone offset. In the read/writeExternal class right before sending/receiving to/from the server we programmatically make a copy of the date and adjust the date exactly opposite of what the normal conversion is going to do. In other words if the user is in PST and server in EST, right before we send to the server, we make a copy of the date and SUBTRACT 3 hours to it. Then when the server gets it, it will be adjusted by ADDING 3 hours to it, thus leaving the exact data, non adjusted, the user entered. We do the opposite coming from the server to client. We make a copy of the date so that the only data that is changed is the data getting serialized and any UI binding to that date will not change because it would be bound to the original copy. Yes, this is a pain, but because of our framework I only had to adjust 2 code generation templates and regen our communications layer. No other code change. One note is that during this programmatic conversion I was getting the client offset at that time. I found that when this function is heavy hit, it did not always return the same offset. I found that every once in a while Flex would return 240 instead of 300 for EST. YIKES!!! So that is why I grab the offset at app startup and cache it. Technically better performing, but if the user changes timezones while logged into our app that is a problem. But we fell that is highly unlikely. Thanks again and if anyone is interested I can show you the exact code. Dale -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Douglas Knudsen Sent: Tuesday, January 26, 2010 11:27 AM To: [email protected] Subject: Re: [AFFUG Discuss] Dates and Timezones yup, we've had to battle this since the Flex 1.5 days. One thing I've done is in my VOs where dates are set is to build a setter/getter that tweaked the TZ. Thus incoming dates in AMF which were at TZ whatever on the server were massaged en route and the converse. To handle user UI TZ choice, could just add this user chosen offset to all dates. So yeah, have to basically build your own Date Class to really do the work. Copy Date.as to your source tree, tweak...monkey patch! I see folks pass the date to and fro as a String often to get around all this, using custom getter/setters to massage things. Kind of defeats the whole "AMF is the life saving tech that we all should use" moto form Adobe though. To add to this mess....I recall a issue with either Flash, Windows, or IE that didn't expose the TZ correctly for a certain subset of folks in AZ where daylight savings time is only partially observed. Douglas Knudsen [email protected] On Jan 25, 2010, at 5:49 PM, Dale Bronk wrote: > Yep, thought we tried java.sql.Date. Just tried it again to make sure. No > change, same issue. I'm looking at Doug's suggestion. Problem with that is > that it seems that Adobe really screwed us by making Date.as final and > timezoneOffset readonly which means it looks like I'll have to actually > manually change the date, which is horrible. Not sure why Adobe would do > that to us... Seems like extremely basic Date functionality. We can assume > that the user wants to see dates in the timezone set on the machine they are > using, but now if the user wants to switch and see dates in another tz, it > is not as simple as just setting the timezone. Huge, huge, huge miss by > Adobe in my opinion. Dates are never easy to deal with, but Adobe is now > making us walk the tight rope on one leg. > > Dale > > -----Original Message----- > From: Dale Bronk [mailto:[email protected]] > Sent: Monday, January 25, 2010 11:20 AM > To: [email protected] > Subject: RE: [AFFUG Discuss] Dates and Timezones > > I'm 85% sure we tried that, but truthfully we have done so many things I > can't remember that actual test. I'm 100% sure we spoke about it, just > can't remember the actual trying of it. > > So, I'll certainly try it again and let you know. > > Thanks, > Dale > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Lukas Bradley > Sent: Monday, January 25, 2010 10:55 AM > To: [email protected] > Subject: RE: [AFFUG Discuss] Dates and Timezones > > I'm guessing you're using a java.util.Date in your Hibernate object. I'd > recommend trying a java.sql.Date field. > > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of Dale Bronk >> Sent: Monday, January 25, 2010 10:51 AM >> To: [email protected] >> Subject: RE: [AFFUG Discuss] Dates and Timezones >> >> We are DB agnostic. Current customers are using MSSQL, but some will no >> doubt be Oracle. We are using DATE as the datatype in the db. I don't > know >> about MySql, but MSSQL and Oracle will still store a time value in a > DATE >> field, just stores as 00:00:00 if none is given. I do not believe the > issue >> is the DB, it is the Date Object in Java and/or Flex and the >> (de)serialization of that object to/from each. They store a blip in > time >> which includes time. If no time is giving, time is defaulted to > 00:00:00 >> (ie: midnight). >> >> I've placed breakpoints in my entities readExternal function and look at >> what is coming in on the IDataInput.readObject() call and at that time > the >> TZ conversion has already happened. >> >> Dale >> >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of Lukas > Bradley >> Sent: Monday, January 25, 2010 10:13 AM >> To: [email protected] >> Subject: RE: [AFFUG Discuss] Dates and Timezones >> >> Do you want the database field to contain a time? What database are you >> using? MySQL? >> >> Take a look at the DATE type instead of DATETIME. >> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On Behalf Of Dale Bronk >>> Sent: Monday, January 25, 2010 9:54 AM >>> To: [email protected] >>> Subject: [AFFUG Discuss] Dates and Timezones >>> >>> I had posted about this before, but never solved it and it is really >>> starting to burn us. Any idea's or techniques would be appreciated. > I >>> really don't want to have to go to passing dates as strings and >> converting. >>> >>> We use GraniteDS because of it's better integration with Hibernate > than >>> BlazeDS. The issue is with dates. I can easily reproduce this with > my >>> desktop and laptop. I simply set my desktop to EST and my laptop to > PST. >>> On my desktop I use our app and create a record with a date. The date >> goes >>> into the DB as 01/25/2010 00:00:00. No time is set in this example so > the >>> db defaults to midnight. Now using my laptop with PST I use our app > to >>> retrieve the record. It displays as 01/24/2010. In debugging, the > exact >>> date is 01/24/2010 @ 9:00pm which is of course the time difference > from >> EST >>> to PST. >>> >>> This is really killing us. We are good with the TZ adjustment when we > are >>> storing dates with times, say a meeting. That we want to adjust per > TZ. >>> But for dates when we only care about the date/no time how can we stop >> this >>> adjustment from happening? >>> >>> For you Hibernate guys and gals, we set these dates in our entities as >>> TemporalType.DATE instead of TemporalType.DATETIME which tells > hibernate >> to >>> only care about the date portion. Doesn't seem to work. Somewhere in > the >>> serialization/deserialization the conversion is done. >>> >>> I know if we change our entities to take Strings for dates that would >> work, >>> but what a pain that will be. >>> >>> Thanks, >>> Dale >>> >>> >>> >>> >>> ------------------------------------------------------------- >>> To unsubscribe from this list, simply email the list with unsubscribe > in >> the >>> subject line >>> >>> For more info, see http://www.affug.com >>> Archive @ http://www.mail-archive.com/discussion%40affug.com/ >>> List hosted by http://www.fusionlink.com >>> ------------------------------------------------------------- >>> >> >> >> >> >> ------------------------------------------------------------- >> To unsubscribe from this list, simply email the list with unsubscribe in > the >> subject line >> >> For more info, see http://www.affug.com >> Archive @ http://www.mail-archive.com/discussion%40affug.com/ >> List hosted by http://www.fusionlink.com >> ------------------------------------------------------------- >> >> >> >> >> >> ------------------------------------------------------------- >> To unsubscribe from this list, simply email the list with unsubscribe in > the >> subject line >> >> For more info, see http://www.affug.com >> Archive @ http://www.mail-archive.com/discussion%40affug.com/ >> List hosted by http://www.fusionlink.com >> ------------------------------------------------------------- >> > > > > > ------------------------------------------------------------- > To unsubscribe from this list, simply email the list with unsubscribe in > the subject line > > For more info, see http://www.affug.com > Archive @ http://www.mail-archive.com/discussion%40affug.com/ > List hosted by http://www.fusionlink.com > ------------------------------------------------------------- > > > > > > ------------------------------------------------------------- > To unsubscribe from this list, simply email the list with unsubscribe in the subject line > > For more info, see http://www.affug.com > Archive @ http://www.mail-archive.com/discussion%40affug.com/ > List hosted by http://www.fusionlink.com > ------------------------------------------------------------- > > ------------------------------------------------------------- To unsubscribe from this list, simply email the list with unsubscribe in the subject line For more info, see http://www.affug.com Archive @ http://www.mail-archive.com/discussion%40affug.com/ List hosted by http://www.fusionlink.com ------------------------------------------------------------- ------------------------------------------------------------- To unsubscribe from this list, simply email the list with unsubscribe in the subject line For more info, see http://www.affug.com Archive @ http://www.mail-archive.com/discussion%40affug.com/ List hosted by http://www.fusionlink.com -------------------------------------------------------------
