search

wingrunr21 / mindbody-api

A Ruby interface to the MindBody API v0.5
http://wingrunr21.github.com/mindbody-api
MIT License
29 stars 46 forks source link

Add ability to specify Timezone(s) #4

Open wingrunr21 opened 11 years ago

wingrunr21 commented 11 years ago

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.

psulightning commented 10 years ago

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.

psulightning commented 10 years ago

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.

wingrunr21 commented 10 years ago

Does the site you are working with happen to be in the same timezone that you have in your settings?

psulightning commented 10 years ago

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.

wingrunr21 commented 10 years ago

Not what I asked. Is the Mind-body site you are working with also in EST?

psulightning commented 10 years ago

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 notifications@github.com 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 .

wingrunr21 commented 10 years ago

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.

psulightning commented 10 years ago

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 notifications@github.comwrote:

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 .

wingrunr21 commented 10 years ago

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.

psulightning commented 10 years ago

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 notifications@github.com 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 commented 10 years ago

Branch disable_advanced_typecasting should have that option turned off

sirdavidwong commented 9 years ago

@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?

wingrunr21 commented 9 years ago

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.

sirdavidwong commented 9 years ago

@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.