>This topic seems to come up repeatedly. I don't know what anyone on the >runtime team tried or why Labriola didn't like it, and I'm no expert on the >topic, but maybe we can collect some information in this thread that will help >create a solution.
They created a SimpleDate class which extended Date but did an override to the time zone and all the time-related getters and setters to be no-ops. It just seemed backwards to me, but they didn't want to inject a new type in the inheritance tree between Date and Object. >The basic goal, as I understand it, is to have a way to record the date >something happened and display that date in all time zones. I think of it as >viewing a printed receipt. For example if I purchase groceries at 9pm Pacific >Daylight Time on Monday, October 7, 2013 and save that transaction to a >server, there are scenarios where someone in India should be able to pull up >that receipt and it should still show Monday, October 7, 2013 even though it >was Tuesday, October 8, 2013 in India at the time I purchased those groceries. This is often referred to as 'floating time' meaning that the time and or date is important but time-zone irrelevant. IIUC, the current "solution" is to save the date as a String. Apparently, that isn't good enough for folks. I assume that's because folks want to do some math or sorting on the date. Now for some questions: 1) Why does the runtime need to be enhanced to support this? >In general, my opinion is that it does not. It would be a great convenience >though and there are a couple of outstanding bugs in specific time zones which >make this harder. Further, Date is final, so I can't change the functionality >on my own. That said, a specific problem with Flex has always had IMO, is that the controls are tied to the concrete Date class. That means there is no way I can be 'in front' of this functionality and I must always provide a control with a real Date object and hence inherit all of the functionality that I may or may not want associated with time zones. In our international applications we actually wrap Date into a new class and changed Flex to use an interface type so we could decide when we wanted the functionality and when we wanted to use just dates or even non-gregorian dates. 2) What do other languages and platforms do to solve this problem? >Many have a discrete concept of a Date versus a DateTime 3) What would be a practical solution if the runtime does not provide this enhancement? 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. The ultimate practical answer for us though was to not use Date directly but rather wrap it so that we could control the offsetting and computational logic per our requirements. Again though, that meant we had to change a lot of Flex code too. 4) What should we do for FlexJS? In our JS applications we do the same as the trick mentioned above. We handle all dates during serialization and deserialization manually and adjust. You could consider not tying things directly to Date. It's important to understand that (with the exception of a few bugs) the player's functionality is correct for a DateTime type. Time is NOT floating. 11pm on Day 5 for me is 2am on Day 6 for someone else. They are the same moment in time. The issue comes from the fact that developer meant to only store the Date portion and we don't actually have a Date type. It gets more complex when one interacts with an application server or Database that does understand how to just store the Date and has to deal with the way in which the various tiers decide to handle that issue. Happy to talk about this at length if it helps. I spent a whole lot of time working on this issue and working with Adobe's i18n team on possible solutions. A lot of big enterprises wrestle with this. Mike
