mindbody-api
mindbody-api copied to clipboard
wingrunr21
Add ability to specify Timezone(s)
MindBody, in all of their wisdom, does not ship timezone offset information with their timestamps. Sometimes their timestamps are in Pacific time, other times they are in whatever the local timezone is for the given site (which cannot be queried). So, some mechanism needs to be built in that can map incoming timestamps to the correct Timezone. This should be capable of being done via the configuration object and via environment variables.
So it looks like the problem stems from Savon. When you do @response.to_hash, it auto converts to UTC. I can use the raw XML and do Time.parse which gives the correct time zone.
I think I have a solution:
Look at commit https://github.com/psulightning/mindbody-api/commit/6a4213c888bc6b9ae50d6eebb9c82e3cc5e6dc47 in my fork. Adds a parsing for any DateTime or Time instances.
Does the site you are working with happen to be in the same timezone that you have in your settings?
I set config.time_zone to "Eastern Time (US & Canada)" in my application.rb. If that isn't set, it should default to use UTC.
Not what I asked. Is the Mind-body site you are working with also in EST?
Sorry, thought you were talking the rails site. Everything entered into mindbody is based on eastern time. Are there some things in the API that return with a time zone?
On Mar 30, 2014, at 10:46, Stafford Brunk [email protected] wrote:
Not what I asked. Is the Mind-body site you are working with also in EST?
Reply to this email directly or view it on GitHubhttps://github.com/wingrunr21/mindbody-api/issues/4#issuecomment-39027167 .
Ok, that's what I thought. MindBody doesn't ship timezone offsets anywhere. The timestamps coming back are usually in whatever timezone the targeted site ID is and do not specify a Timezone offset. They appear in UTC because without a specific setting Ruby assumes a timestamp is in UTC when parsing it. Dealing with this issue is made more fun when clients have sites across multiple timezones and query against multiple site ids at a time.
In your situation, timestamps are in EST and you have Rails set to assume EST. If you changed Rails to central time, I bet your timestamps would no longer be correct.
The Response object is not the correct place for this to be happening anyway. The MindBody models are hydrated via Virtus attribute declarations. Virtus should be handling this issue when it is hydrating the rest of the models.
Yeah I tried setting default value in Virtus, but the problem originates when @response.to_hash is called. This auto parses any datetime objects into UTC. So, when Virtus receives the date string, it has +00:00 in it.
On Sun, Mar 30, 2014 at 11:58 AM, Stafford Brunk [email protected]:
Ok, that's what I thought. MindBody doesn't ship timezone offsets anywhere. The timestamps coming back are usually in whatever timezone the targeted site ID is and do not specify a Timezone offset. They appear in UTC because without a specific setting Ruby assumes a timestamp is in UTC when parsing it. Dealing with this issue is made more fun when clients have sites across multiple timezones and query against multiple site ids at a time.
In your situation, timestamps are in EST and you have Rails set to assume EST. If you changed Rails to central time, I bet your timestamps would no longer be correct.
The Response object is not the correct place for this to be happening anyway. The MindBody models are hydrated via Virtus attribute declarations. Virtus should be handling this issue when it is hydrating the rest of the models.
Reply to this email directly or view it on GitHubhttps://github.com/wingrunr21/mindbody-api/issues/4#issuecomment-39029143 .
The type coercion on the savon side is done via nori typecasting. That typecasting should probably be disabled so Virtus can handle it (#19 is tracking that).
Still only solves the problem for a 1 timezone use case.
Agreed. But at least there would be a better ability to control through Virtus.
Sent from my iPhone
On Mar 30, 2014, at 12:39, Stafford Brunk [email protected] wrote:
The type coercion on the savon side is done via nori typecasting. That typecasting should probably be disabled so Virtus can handle it (#19 is tracking that).
Still only solves the problem for a 1 timezone use case.
— Reply to this email directly or view it on GitHub.
@wingrunr21 is this still the case with the v0.5 API?
That is, timestamps that come back from the API are in the targeted SiteID's timezone. So, if you were talking to SiteID=1 in PST and SiteID=2 in EST, and you got the same timestamp in a response from both sites, they would in reality be off by 3 hours?
To be honest, the client I was using this library with has moved on and I haven't had a chance to check MindBody's new sandbox. If they are still on the v0.5 API though, my guess is that it is still a problem.
The issue is that the timestamp is in the timezone of the site but the timezone offset is not returned. Ruby assumes GMT (or whatever your default timezone is) and then calculates the offset timestamp based on whatever you are specifically asking for.
@wingrunr21 yeah pretty sure it's still an issue with v0.5. As another sanity check, changing the business's time zone on the sandbox did nothing to affect the timestamps I received.