|TimeZone in BudgetOrderService||Alexander Nitschke||6/21/12 6:16 AM|
I feel there is an apparent lack of questions for the new features of the 201109_1 API version. Well, we totally welcome the new BudgetOrderService as we are able to eliminate one more manual step in the account creation process. However, I have a question regarding a detail: The fields startDateTime and endDateTime in the BudgetOrder need a time zone information, fair enough (despite the TimeZone displayed always is the one of the account, so this wouldn't really be necessary IMO). But I was only able to use America/Los_Angeles like in the linked description, other time zones like Europe/Berlin were rejected with an API-exception that the timezone couldn't be identified which is a bug I think.
I like to think that the possible time zones here should be the same as in the CreateAccountService, because I'm not particularly fond of programmatically incorporating differences in daylight saving time from Los Angeles to various time zones of our customers (or eliminate the time zone altogether and assume the account time zone - like in the GUI). Additionally I suggest some code for "now" for the startDateTime since this actually is the only startDateTime we use.
Thanks for answers
|Re: TimeZone in BudgetOrderService||Jim McCabe||7/18/12 1:12 PM|
Did you find an answer to this question?
The documentation doesn't really describe the legal values that the API will accept. Is it only America/Los_Angeles?
|Re: TimeZone in BudgetOrderService||Kevin Winter||7/24/12 2:12 PM|
Jim posted some answers here. I'm going to try to get the documentation updated to make this more clear.
- Kevin Winter
AdWords API Team
|Re: TimeZone in BudgetOrderService||Allen||8/20/12 6:47 PM|
I'm finding the same issues. My biggest issue is that without knowing the offset and current daylight savings status, it is hard to compare dates if date overlap occurs on submit (in cases where someone has manually extended a budget period). With V13 I could compare everything as UMT and could handle most overlap and gaps.
I agree it should be like the GUI / no zone issues to deal with.