jason - 12/May/09 10:25 AM I think perhaps we can add this as a single call to get the server timezone, rather than adding additional information to each timestamp returned by the API (currently Pulse does not store timezones with each stamp anyway, so it would return an identical zone for every stamp).

jason - 13/May/09 01:31 PM Looking into this more, I found we use the unambiguous value of milliseconds since the epoch (UTC) for our stamps internally, but hoping to be helpful turn these into Dates when passing the out of the API. The problem with this is that XML-RPC dates do not preserve the timezone information, hence there is no way on the client side to interpret the date without guessing/knowing the server timezone. My primary solution for this was to add two new fields to results: startTimeMillis and endTimeMillis which contain the unconverted milliseconds since the epoch. As these are 64-bit values they are pased as strings in the XML-RPC struct. My guess is that these will be fairly easy to work with to solve the reported use case. Additionally, I have added a getServerInfo method that returns a struct of simple string values with information about Pulse and the environment it is running in. This includes the timezone (user.timezone) and also the current time (current.time) in milliseconds since the epoch on the Pulse server. Refer to change 5907.

jason - 14/May/09 10:37 PM Merged to trunk in change 5913.