This May we will enable AdWords and MCC account owners to set their accounts' time zones. This means that all metrics returned for a given account will be reported in that account's time zone (currently all accounts are reported in US Pacific Standard Time (PST) – the time zone for Google's headquarters in California). In addition, billing and budgeting cycles will be based on each account's time zone.
Advertisers and MCC managers will be invited to set their time zones in May, at which point we will release a new version of the AdWords API that includes "set" and "get" time zone functionality. We plan to release more detailed/technical FAQs (via the AdWords API Blog) as we get closer to the launch date.
In the meantime, we'd like to give you a high-level overview of time-zone related functionality and implications for developers.
What is Time Zone Support?
Advertisers can select any time zone in the world for their AdWords account. All reporting, ad serving, and billing will be based on the time zone set by the advertiser. Advertisers or MCC managers who choose not to establish account time zone settings will continue to have their accounts managed in US PST, as they have been in the past. It is important to note that each account's time zone may only be set once, so advertisers should be careful when setting their time zone.
What will change in the web application?
Starting in early May, existing advertisers who login to the AdWords website will receive an invitation to set their account’s local time zone. New advertisers will be asked to specify their local time zone during the account setup process.
How will Time Zone support impact AdWords API developers?
The interfaces for submitting and returning date/time values already support local time zones (even though all data is currently submitted/reported in US Pacific Standard Time). Therefore, the impact should be minimal.
- You will be able to get and set your local time zone through new methods in AccountService, as well as get the effective date of the most recent time zone change.
- Statistics will be collected at standardized times within each account's local time zone boundaries. For example, if a customer in Tokyo sets her account for Japan Standard Time (JST), that account's stats will be collected from midnight to midnight, JST. Likewise, accounts set to PST will have their stats collected from midnight to midnight, PST.
- The start and end time specified in report jobs sent to ReportService will be interpreted in the account's local time zone.
- Where appropriate, date parameters will be used instead of date-time (xsd:date instead of xsd:dateTime). This includes the start and end day of a campaign, the start and end period for stat methods, and the start and end day of report jobs. The day will automatically be interpreted in the account's local time. If a time zone is specified along with the day, it must match the account's local time zone.
- If you schedule a single report to aggregate data across multiple accounts (and those accounts are in different time zones), the report will aggregate each account’s local daily data.
- If you schedule a single report to aggregate data across multiple accounts (and those accounts are in different time zones), the report will aggregate each account’s local daily data.
Will this change be backward-compatible with V3?
Once you begin setting time zones for your accounts, you will still be able to use the current version (V3) of the API. However, there will be one difference. In V3, all API calls will still return account statistics in PST (regardless of each account’s specified time zone) except for reports, whose day boundaries will be calculated in each account’s local time zone.
Once you migrate to the new version (V4), all API calls will return statistics and reports calculated in each account’s local time zone. However, we understand that some developers may want to return all account statistics in one time zone. Therefore, you will be able to access all account statistics in PST by passing in a flag to the stat methods. The coming release notes will have more information on this.
We hope you find this information helpful, and we promise to release further technical details as soon as possible.
-- Rohit Dhawan, Product Manager
