2 Replies Latest reply on Apr 25, 2011 12:02 PM by HAGP

    Best way to manage date/time variables across different timezones

    HAGP

      I have an application that relies heavily on time accuracy. At the moment everything is fine, but soon the system will service customers across multiple timezones. The default behavior of the Date class is to show dates related to the current timezone, is there an easy way (setting) to override this behaviour? The system should show the time entered regardless of the timezone it was entered on.

      I use CF 8 for the back-end, and MySQL 5.1 to store data. The front-end is Flex 3/Air 2.

      I have looked everywhere, and things like saving dates as strings, or long ints, but if possible, I'd like to find a solution that does not involve dramatic changes to my database/code.

        • 1. Re: Best way to manage date/time variables across different timezones
          UbuntuPenguin Level 4

          From what I have seen, dates if you are using serialization are sent over as UTC.  When they get to the backend, they are stored as whatever timezone your server is in.  When Flex receives a saved date from your service, it will convert it to the users timezone.  I don't know if that answers your question, and I must admit I am a little hazy on my timezone knowledge.

          • 2. Re: Best way to manage date/time variables across different timezones
            HAGP Level 1

            Thanks for your reply, UbuntuPenguin,

            Your explanation is correct and what I'm trying to find out is an easy way to override that behaviour.

            As an example of what the issue is, let's say an event was entered here, in Toronto,ON, at 3pm, if a customer in Arizona sees the time, he/she will call us immediately to inform us that the event it's supposed to happen at 3pm, and not at 12pm (time that they see with the different timezone).

             

            As far as I've seen, the "best" way to approach this issue is by using  the transient tag during data transfer and compensate for the time  difference in the client timezone vs the selected "system" timezone  using getters/setters, but that implies storing the wrong date/time and  locking the system into one timezone, and it's just a hack that may  bring undesirable consequences in the future.