Let me elaborate on my previous comment. In my opinion, we could introduce a new type (or more than one), but we should make modifications to framework components.
For example, the DateField may use the new DateWithoutTime class directly, because it doesn't supports time resolution in user interaction. This would prevent entered dates to shift +1/-1 days due to unexpected timezone corrections applied internally. Going further, we may actually introduce different classes: - FloatingDate (used by DateField when useFloatingDate is true) - FloatingDateTime (used by a future DateTimeField when floatingDate is true) - FloatingTime (used by a future TimeField always, as timezone corrections are meaningless on the time part alone). This, along with some utility methods (such as FloatingDate.fromDate, FloatingDate.toDate and so on) and with built-in serialization support in BlazeDS, could mitigate the problem. Of course, full local date math with custom timezone is a much difficult (and different) thing to accomplish. If we wanted to move in this direction, maybe a port of joda time would be a good strategy… for historical timezone and DST, it relies on its own updeatable tzdatabase AFAIK, so it would be independent from Flash internal implementation (Flex SDK releases could ship the most recent version, and maybe provide projects a way to load a custom one as an asset). The drawback could be some initial confusion for existing and new users, put in front of many different date and time classes (native/flex/floating/nonfloating/ecc). Just my 2 cents… Cosma 2013/10/9 Paul Hastings <paul.hasti...@gmail.com> > On 10/9/2013 7:04 AM, Michael A. Labriola wrote: > >> Besides of the "Date without time" issue, there is also the issue handling >>> regular Date+Time in different TZ. >>> >> >> That's a lot more difficult, especially, as you mention because of DST as >> it >> requires data tables to make those decisions historically. >> >> I think the only way you can achieve this is changing every hard >> dependency >> in Flex on Date to use an interface type. >> > > i find it somehow comforting that i'm not alone in timezone hell ;-) > > for "historical" dates we've used calls back to the server (coldfusion) or > during data retrieval where we could access the whole tz database. but the > issue then became what's "historical"? which ended up as "whatever the > client said it was", not the best approach. > > really curious to see what folks have done to solve this. > >
