Documentation says the timestamps in the activity atom feeds should be UTC, however, it appears that they are UTC -8 most of the time I pull them. Occasionally, that offset appears to change. I'm using Appengine, so maybe it's relevant to the querying server somehow? Or the server in your complex being queried?

Hi Joey,

I'll have to get one of our guys to look into this. Thanks for reporting and sorry for the delay in responding.

Rhonda

 

Thank you, I've been adjusting the time by 8 hours for the interim and appears to work most the time.

 That's too much work, lets see if we can fix this :)

Rhonda

 

Please :) I should note that occasionally it appears that the timestamp has a different offset. The results occasionally appearing with a completely different time.Just a hunch from a guy who's more of a SA than a developer, you may want to check the local timezone of the servers delivering the content. If you have something that keys off of the location of the request, you may want to change it to a static UTC. The reason I bring up the client is that as I'm using appengine as my host, my requests can be coming from anywhere in the world, I'm not using a dedicated server. Of course, I know nothing about your architecture, so I could just be completely not helpful.

 Also, can you let me know when you think there's a resolution so I can update my code to reflect the changes? Thanks.

Heya, this doc was recently updated re: timezone formats and it might help. Let me know :)

http://wiki.developer.myspace.com/index.php?title=Date%2C_Time_and_Timezone_Formats

 I'll check it out as soon as I can, hopefully sometime this week. Thanks!

Hi Rhonda,

thanks for the documentation. Regarding the dateFormat and timezone parameter, the following behavior of the MySpace API appears to me as being a bug or at least an error in the documentation stated above:

A call of

/v1/users/474496812/profile?dateFormat=iso8601

in the OAuth Tool (http://developer.myspace.com/modules/apis/pages/oauthtool.aspx) yields a

...
<lastupdateddate>6/23/2009 6:00:03 AM</lastupdateddate>
...

It therefore seems that the parameter dateFormat=iso8601 is ignored, as the format does not seem be ISO8601.

Even stranger, an addition of  timeZone=-8, resulting in a call of

/v1/users/474496812/profile?dateFormat=iso8601&timeZone=-8

in the same tool returns in the same position a

...

<lastupdateddate>2009-06-22T20:00:03</lastupdateddate>
...

Which is a contradiction to the statement "When the timeZone query string parameter is absent, MySpace uses a default value of timeZone=-8." in the document above.

Could you please clarify this issue?

Best regards,

  Tim

It appears that paticular api call does not honor the timezone and dateformat parameters. 

Can someone please take a look at this?

I just want to give my thanks to whoever posted this. This answers a lot of the questions I've had over the past eight months. This may also be the solution to the install callbacks working intermittently.

 I've been modifying the time after retrieving it to GMT, then working from there.