I've read here and here that the GA timezone depends on the timezone set in the GA account. Does this mean that I can't get the UTC data for each day?
Something you can do is set the Time Zone country to United Kingdom and the Time Zone itself to GMT+00:00 GMT (no daylight saving).
It's a bit of a hack, but GMT and UTC are considered interchangeable. UTC replaced GMT, so although GMT is no longer officially maintained by the scientific community, it's still basically the same thing.
From the left-hand menu, go to Admin > View > View Settings.
You answered your own question.
Google Analytics dates and times are in the time zone of the Google Analytics account. The website displays in that time zone and the Google Analytics API returns data in that time zone.
You have tagged your question both Google Analytics and Google Analytics API. If you are using the API and want it in UTC you will have to convert it after you have extracted the data. If you are using the website there is nothing you can do. (Besides removing API tag from your question)
Setting your account to GMT/UK does not achieve this because for part of the year The UK observes daylight savings, taking it out of sync with UTC. Iceland works for now because it is UTC all year round.
This is a hack because a country's time zones and whether or not they observe daylight savings can change. Also note that if you set your location to Iceland for the timezone google will think your business is in Iceland and send you offers for advertising and things in Icelandic context!
What we need is for google to support UTC as a reporting time rather than only supporting places. You can enter your real location on your google analytics account and then set UTC (Iceland) as the reporting time for each property, again not perfect.
Related
Here's a riddle (serious question actually): if two users are on GA at the same time but are located in two different timezones, do they see the same data?
I ask because an associate and I are observing a dip in traffic but at wildly different rates: I see -17% on my side but he sees -45%. I'm currently in Pacific Standard Time and he is in Australian Eastern Daylight Time.
Any insights?
You can view or set up a timezone in Google Analytics View.
By default, Google Analytics will work with this timezone set. However, you can adjust the time zone per view, which could come in handy for sites that operate in a different timezone than you.
Friday the 22nd of november we've gotten over the course of 2 hours two different conversion amounts in Google Data studio (=> pulled data from Google Analytics).
At 15.00 pm we hit 22 conversions. Some time later at 17.00 pm we hit 9 conversions.
At 14.45pm the website (https://zaza.rocks) went down. So not willing to corrupt our data a test IP address was excluded from Google Analytics.
With that being said it seems strange that the conversion amount changed during that time window due to an exclusion of 1 IP Address. So I am wondering:
Can an IP exclusion change previously acquired conversions in a short time window?
Perhaps Google Data studio pulled wrong data due to a bug from 14pm to 17pm
Another reason?
Thanks for helping.
In Google Analytics the data can be considered stable after 48 hours (within that time they can be reworked).
If you have converted on the same day that you applied the IP filter (which excludes the network from which you made the conversion) you must consider, i.e., that after midnight Analytics reprocesses the data of the day and therefore applies the filter to the whole day just ended (even if you added the filter only in the afternoon).
I have the following link for a user to create a Google calendar event
https://calendar.google.com/calendar/render?action=TEMPLATE&text=Your+Event+Name&dates=20140127T224000Z/20140320T221500Z&ctz=America/Los_Angeles&details=For+details,+link+here:+http://www.example.com&location=Waldorf+Astoria,+301+Park+Ave+,+New+York,+NY+10022&sf=true&output=xml#eventpage_6
I originally found this out using the example from Link to add to google calendar
The issue I am having is to do with the time part of the URL which is
&dates=20140127T224000Z/20140320T221500Z
to break this down the format for this in which Google uses to determine the start/end date and time is
Ymd\\THi00\\Z
So you understand Google uses GMT as a standard time in the url and converts it correctly according to the users settings in their Google account. For instance (GMT-07:00) Pacific Time
So let's take just the start time of this URL which is
224000 which is Hi00 or Hour:Minutes:Seconds
In my Google calendar, my timezone settings are set to Pacific which is -7. Converting 224000 GMT to -7 Pacific you get 154000 which should be 3:40 PM
Problem is when you click the link, (if you are pacific) it is showing me the start time as 2:40 PM
What's even weirder is the end time which is 221500 shows as 3:15 PM. The end time hour is still the same as the start time but shows 1 hour ahead. I get that Google is probably assuming that I mean 1 hour ahead and makes that change for me, OR by default Google probably adds 1 hour more from the start time automatically.
I am not sure if I am understanding the format Google uses GMT in the URL or there is an issue with my coding and how I am representing that. Anyone have any info on this?
You may want to check this page wherein it discussed how Google Calendar uses time zones. As mentioned,
When you create an event, you'll see it in your local time zone. It will also show up in the local time zones for anyone you invite, even if they're in a different time zone.
And, on Daylight savings time:
Google Calendar uses Coordinated Universal Time (UTC) to help avoid issues with daylight savings time.
When events are created, they're converted into UTC, but you'll always see them in your local time.
If an area switches their time zone, events created before we knew about the change might be in the wrong time zone.
With this, you may want to try the given workarounds in this thread and see if it will help you.
I have a question about dealing with date & time in my web application. The application will sell monthly subscriptions. It shows dates only when clients buy and cancel subscriptions. Clients can buy additional services in the middle of the month. Application calculates a pro-rata to charge the client until his anniversary date.
I will store dates/times in UTC. It is only for US clients.
I am considering the following options and I would love to get feedback from more experienced developers:
1 - always present dates in EST. I can include a small caption explaining that all subscriptions uses EST. This would be simple as I would not have to deal with clients' timezones. However I am not so sure if clients would be put off by this. Any thoughts?
2 - always present dates in EDT. This would probably not work very well as it would be harder to explain the reason for using it. However I believe it would be simpler to process than EST.
3 - ask for client's timezone information when he signs up for the service and use that information. I don't think this would add too much complication, however I would have to offer them an option to change timezones and I would have to decide what to do with existing subscriptions when there is a change in timezone. If I go with this option I would ask the client to pick the timezone from a drop-down list.
4 - ask for client's location (City and State) and calculate the timezone myself.
5 - try to guess client's timezone based on his IP or another method (ideas???).
Options 3, 4 and 5 would probably be the most user-friendly. Option 1 seems to be the most straightforward to implement.
Sorry for the long post. If you took the time to read it, would you mind taking a little more time and sharing your thoughts and experience?
Thank you.
UPDATE 1 - 9/3/2011 - 17:08 MST
Just found out that PayPal records transactions using PDT and shows them to the client using the client's local timezone they setup when they signed up with PayPal.
I am now inclined to:
1 - show current date using PDT (to align with PayPal) - I will probably change the code to show date & time PDT. Currently I am only showing the date. I believe it will be clearer to the client if I also show the time.
2 - I will not show the anniversary date. I will let PayPal handle that. I will simply state that it is a monthly billing.
3 - When clients add a new service I will calculate the pro-rata using PDT and I will give them a three day grace period to account for timezone differences (thanks to Robert Levy below for suggesting it) and PayPal processing (I don't want to charge them a pro-rata amount if they are only a couple of days from their regular monthly charges).
Any thoughts?
Update 2 - 9/3/2011 - 21:01 MST
Just a quick update. After further research I found out that PayPal does send me a transaction date back. I am not going to show any dates until the client pays at PayPal and I receive confirmation. I will show PayPal's transaction date in the client's receipt.
Sounds like a plan. What do you think?
Just add a grace period of 24 hours from UTC. Easy to code, no extra UI, and unlikely to upset any customers.
I want to implement timezone in my web application. I researched and saw most web app use a GMT dropdown, here is the link to that dropdown http://www.attackwork.com/BlogEntry/6/Time-Zone-Dropdown-Select-List/Default.aspx
Then I saw this article suggesting UTC is the way to go when it comes to implement timezone. https://web.archive.org/web/20210513223048/http://aspnet.4guysfromrolla.com/articles/081507-1.aspx Basically it's saying don't use DateTime.Now instead use DateTime.UtcNow
My questions are,
Is there a dropdown of the timezones in UTC, like the first link I showed there is one on GMT?
Should I really use UTC or GMT?
.NET 3.5 provides the TimeZoneInfo class which should make it relatively simple for you to populate a dropdown with time zones. GMT came before UTC and UTC was officially instituted on January 1, 1972. See this link for more information. For today's purposes, the two are pretty much synonymous, though they have different historical origins. Use whichever looks and functions better for your purposes.
I'm not sure if this is what you intended to ask, but in your database you should always store timestamps in UTC/GMT (as noted by others they mean essentially the same thing). For each user of your web app, store the time zone preference.
Then whenever you display the timestamp for something to a user, convert the UTC time in the database to the user's timezone.
GMT (Greenwich Mean Time) is the same as UTC (Universal Coordinated Time). This isn't an either/or choice - use it :)
Use Localization settings, functions and features anywhere possible.
If you aren't running against SQL Server 2008 or don't want to abstract timezone management to the database, you should store all times as UTC/GMT and apply the timezone difference based off the user's profile setting, so that users from all around the world can see timestamps on events in their local time.
The distinction between UTC and GMT is probably too fine to bother with in your code. However, it's probably a good idea to always save and process times internally with zero timezone offset, and deal with it as a presentation concern.
It's also possible to use JavaScript to determine the user's probable timezone: examine the timezone offsets for some pair of Date objects reasonably close to the solstices (even January 1 and July 1 makes a suitable approximation) to obtain a coarse timezone identification. Feel free to use this information to determine a default timezone, but do allow it to be changed by the user: JavaScript doesn't provide sufficient detail to select the exact timezone with national and regional historical shifts, and it may not be enabled by the user anyway.