Flurry analytic default time zone is PDT . I am not able to change it into IST. Can someone guide me?
All time zones in Flurry use pacific standard time by design and the timezone can not be changed. One notable exception is the "Time of Day" metric which shows the metrics based upon the end users time zone.
The documentation for this feature may be found here:
https://developer.yahoo.com/flurry/docs/analytics/lexicon/timeofday/
Related
I am looking at Azure Portal for my App Insights usage.
In the volume trends I can see that about 20MB of metrics ingested per day.
But under estimated costs I see custom metrics estimated usage is at only a few bytes.
Why is there a difference in these numbers? Do they mean different things?
I can see custom metrics I log from the app in the customMetrics table, despite the usage staying at 38 bytes for quite some time now (atleast a week). I'm concerned if the monthly usage would jump when I hit the 150MB free limit.
This is a bug in query in backend. The product team has been fixed it and plan to deploy the fix by the end of next week. Please keep an eye on it. I'll update this thread when I get any feedback.
We're transitioning to a managed service provider for our IT service desk and deskside and we're working out the details of their SLAs. Many of the SLAs are based on ticket status. An example of this is the following:
"Measures the amount of time it takes to assess, schedule, test, and package application packages before they are available for User Acceptance Testing."
My first thought was to try using SLAs to measure this, as they neatly tie together calendars and priorities, but I'm having a really hard time finding any information about how I could do this.
Now I'm looking into using the TKSTATUS.STATUSTRACKING attribute on tickets, but I believe this just tracks straight 24/7 time instead of taking into consideration any calendars.
Has anyone tried this before? Any suggestions?
We are in a similar process, but we are measuring time on site of vendors for our work orders. Opposed to using any SLAs we have diffrent statuses which mark different events. Then when we want to know how long it took for an event to finish, we look to see the time required to change status in the wostatus table.
I'm working on an application to connect to the Google Adsense API. As I'm based in the UK, my reports on the Google Adsense web login are all set to UK local time. However, the API data all seems to be solely in Pacific Time, AKA Google Standard Time :-)
This isn't necessarily a huge issue, as it doesn't affect actual earnings. But it does make it harder to track things like CPC and CTR on a daily basis. It would be easier if I could drill down into the data to hourly level, as then I could easily reallocate out-of-zone hours to the adjacent day. But that doesn't seem to be an option either, unless I'm missing something.
I've searched the documentation, but can't seem to find any means of controlling the timezone of API data. Is there any way to get the APi to deliver the data in a local timezone, or do I just have to put up with getting my reports in Pacific time?
As a developer you can't define a time zone to use, but as a publisher you can change your local time zone in the AdSense web interface. After that, you can use useTimezoneReporting when requesting a report.
Read the full explanation and "Things to watch out for" in:
https://developers.google.com/adsense/management/timezone
Situated in the UK, I request a saved report from AdSense API and with "yesterdays" data.
When triggered after midnight our time it pulls data from the day before yesterday...
I didn't know the API was functioning on PST time and just believed it would follow the local timezone set on our account.
Even though the documentation in the comment above mentions reports will be done in "local time" when set in your account, the API will still operate calls based on its own timezone (PST). +8 hours GMT.
So if you need to get "yesterdays" report, be sure to set the date on your call or adjust your schedule to match the PST time zone.
I signed up for a 30 day Azure trial 3 days ago. I have 2 vms. Today, I have 2 messages popping up in my Management Portal.
Your Free Trial expires in 25 day(s). Click here to upgrade now.
Based on your usage history ($21.52/day), you might use your remaining credit in about 3 days.
25 days left $67 credit remaining
I feel like I cut the "speed-up countdown" wire on a time bomb in an 80's movie.
I'd like to fully evaluate Azure and I'm just getting started. Clearly I missed something along the way that is preventing me from getting the full trial period.
Microsoft Support just gives me Azure's sales phone number.
Does someone know what I need to do to get a trial extension and stop the countdown from going too fast.
Thanks!
There isn't a way to extend the trial period. If you have disable the spending limit, you account would operate without any problem, but yet, you would start incurring cost.
These are the ways you cut down costs
Reduce the size of isntance - say small ( A1 )
Recduce the instance count
At any point in time if you are not using your instance, you can stop the instance and you cost near ZERO cost during that time.
If you have MSDN Subscription or BizSpark Subscription would would get $150 everymonth as credits
I have noticed that costs can be quickly used if you keep dropping and creating the database for testing purposes on azure, best to use existing database
So Azure stores datetimes in UTC. What is the best way to handle it if my system need to have timestamps in, say, US Eastern Time? Do I store them in utc, but handle just displaying timestamps by formatting them? Do I format/offset timestamps before storing them in the database? What is the best practice for solving this issue?
I always advocate for storing in UTC time as it is the standard time in which you can calculate any other times zone off of. This means if you have a service in which any one can connect to from any location, it is easier to either detect the timezone the user in currently in based on their system, or have them save the timezone they would prefer to see the time set in from your application.
this thread had a very large discussion which talks about it at length, which you might be interested in reading to help make your decision. If you decide to store UTC and convert the time, here is a post explaining How to convert from UTC to Local Time in C#
Storing time in any persistent store (cache, db, queues, etc.) - always use UTC.
Time in User Interface - get UTC from your APIs (REST) and show it in the local system time (based on users' system).
Additionally, application can have an option or user settings to make timezone configurable.
Remember if you have multiple servers in a distributed environment, it is must to synchronize the clocks in all the servers.
Thanks.