Posted on Tuesday 15 February 2005
Dates are a pain to handle in AMFPHP 0.9b. The timezone setting is lost in the conversion from Flash date to PHP int. But the timezone is very important to know since without it we can’t figure what was the time on the client’s machine. A typical problem is choosing a date using the DateField component. In this case we need to know the client time, not the server time, because if they are in a different timezone and the date is stored in a database, it may very well end up on the day before the client’s chosen date if the server is in a timezone to the west of the client.
The obvious way to solve the problem is to send an array or an object instead of an int. The trouble is that this will break many of your current projects. Another way is to have a $gateway->setDateHandling() function to switch this behaviour. I don’t like this option because you’ll need to check that setting if you want to offer an AMFPHP-based service for public download (think magic quotes). It can’t be set for each service individually since the problem is at the deserializing level and it’s only after deserializing that I know the name of the service to be able to fetch the methodTable.
A less drastic solution is to send the date as a string “12313 -5000″ where the first number is the time and the second the offset. Because of the way PHP handles string to int handling this won’t break a lot of installations. For example, date() should return the correct value. But this is awfully hacky and if the user has a timestamp field in a database and naively tries to store it using sprintf(%s)… you can see where this is going.
I already have a wonderful DateWrapper class that has getClientDate, getServerDate and getTimezone methods that works like a charm. If I send an instance of that instead of an int and break your AMFPHP installations, for dates, do you mind? Do you have a better idea?


