> 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.
