Hi, Besides of the "Date without time" issue, there is also the issue handling regular Date+Time in different TZ. The requirement is to be able to do Math on Date+Time locally (not on the java side) that is TZ aware, and manage DST properly. I spent several months working on it and from what I understand, others did the same. - What were the business requirements ? - What techniques did people use to met the requirements ? - Could we imagine having a decent implementation of this in pure Flex, something like a partial porting of eg. JodaTime to Flex ? - Is it "feasible" to change all the time-aware Flex components ( DateField, DateChooser, Charts, etc.) so that they can use Date or something else (maybe through an interface as suggested in this thread) ?
Maybe I should open another thread on that, not to pollute this one. Regards, Maurice -----Message d'origine----- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mercredi 9 octobre 2013 00:44 À : dev@flex.apache.org Objet : RE: Date without Time (Was: Re: Adobe Bugbase: Bug 3643917 Updated: Date/time gets messed up by the client locale time zone setting) What about them? For Doug and Mike, was it really easier to do custom AMF and timezone math vs just creating a custom DateWithoutTime class and transfer the Date portion to/from the Date values in the components? -Alex ________________________________________ From: Cosma Colanicchia [cosma...@gmail.com] Sent: Tuesday, October 08, 2013 3:17 PM To: Apache Flex Developers ML Subject: Re: Date without Time (Was: Re: Adobe Bugbase: Bug 3643917 Updated: Date/time gets messed up by the client locale time zone setting) What about current SDK methods and componente that require Date objects? (e.g. DateField, formatters, validators...) Il 08/ott/2013 22:22 "Doug McCune" <d...@dougmccune.com> ha scritto: > > In all of our code for applications requiring this feature, we > > specifically handle the serialization/deserialization manually. If > > one takes pains to store all of their Dates in UTC at 00:00:00, then > > you can > do > > the math whenever you serialize or deserialize to look at the > > timezone offset and create a new UTC date that mimics the functionality you > > need. > > It's a pain, but its viable between a combination of serialization > > and using formatters that 'adjust' based on the timezone offset to > > give the appearance of floating time. You get the benefits of the > > string and still get Date math, but it takes work. > > > > This is exactly the method we settled on as well for our app as well. > We had the requirement for Dates to work exactly as Alex explained in > this thread. We use custom AMF encoding/decoding to include the server > timezone offset in the serialized version. Then we do the math to make > the adjustment on the client in the decoding. It is a huge pain in the > ass, but it was the best we could come up with. The fact that Date is > a final class is another big PITA for us. >
