We're working on migrating to Office365/M365 and when we make an API call to the Microsoft Management API for status, the statusTime field is yesterday. Any ideas why?
https://manage.office.com/api/v1.0/(tenant)/ServiceComms/CurrentStatus
Here's a partial json from the Exchange Online status:
"Status": "ServiceRestored",
"StatusDisplayName": "Service restored",
"StatusTime": "2018-10-01T18:49:36.4528522Z",
"Workload": "Exchange",
"WorkloadDisplayName": "Exchange Online"
StatusTime is exactly 1 day behind from my current timezone. The time appears to be in UTC but its UTC - 1 day. I'm confused why? I thought it would be current status.
Any ideas?
Thank you.
When you call to the Microsoft Management API for status, you will get a real-time view of current and ongoing service incidents and maintenance events.
If you want to display the current time zone, you could try to switch time zones locally.
The Microsoft Management API will not return your current timezone.
For more information, please review the following link: Get Current Status
Related
I am attempting to create a vacation leave calendar for my team using the Microsoft Graph API. I have successfully used the /me/calendar/getSchedule endpoint as described in https://learn.microsoft.com/en-us/graph/outlook-get-free-busy-schedule.
However, the response does not include all-day events. Most people book leave for multiple days at a time. I would expect to see "oof" events (status 3) for whole 24 hour periods, but instead there are none.
Is there an option I am missing or another API that can provide this?
I am using Microsoft Graph API delta queries for downloading some information (messages, contacts, events) regularly. But sometimes I get this error:
{
"error" :
{
"code" : "SyncStateNotFound",
"innerError" :
{
"date" : "2018-06-01T06:31:24",
"request-id" : "47e918a9-ce5b-42b4-8a86-12b96c93121a"
},
"message" : "The sync state generation is not found; generation=605;[highest=841][841][839][840]."
}
}
I can't provide you steps for reproducing because I don't know how to reproduce it. It happens sometimes on production environment.
So I have some questions:
What is generation in Microsoft Graph API? Is there any available documentation about it? I didn't find anything useful in the Internet.
Why delta links expire? Delta link expires by time or some iterations of using delta links? Can I save my delta link in my database and in a e.g. 1 year use this delta link for syncing again?
How to avoid delta links expiration? Are there any lifehacks?
What should I do if I got this issue? Full resync and getting new delta link?
Is it a bug or feature?
Every time you sync, a new sync token is generated. We store the current sync token along with the two previous ones. This helps us in cases where we advance the sync on the server side, but something happens transmitting the data to the client so they don't get the new token value. In such cases, we can "fallback" to the previous sync token so that the client doesn't have to resync everything. But these three stored tokens change with each sync - the oldest one gets dropped and we advance. In your case, you are passing us a delta token that is around 230 generations old. That token is long gone.
Another thing to consider is that an "inactive" sync token will hang around for around 90 days at which point we consider it stale, pour gas on it and set it on fire (not really).
We're using ejabberd as our xmpp server and iphone xmppframework for client side.
The problem is when we get the offline messages the timestap that is written in the message is in actual date/time format but the timezone of the server is different than the clients time zones so at this point the things are getting messy.
We're using a same approach while querying Last Activity of a user(XEP-0012) , but in last activity xep the server returns the information as "how many seconds ago the user last logged in to server" so in this way we can apply seconds difference to our clients time and found the message delivery date/time so there is no problem in Last Activity query.
But in delayed delivery , ejabberd sends an exact date and time value and clients confuses about the conversion(Date and time of each client may be very different from each others)
Does anyone know how can we fix that problem? Is there any way to configure ejabberd to return "seconds passed information" until offline message send ?
By the way we're using latest ejabberd version.
Thanks
XEP-0091 (Legacy Delayed Delivery) says:
The timezone is be understood as UTC.
So you need to convert the time from UTC to the local time of the client in order to get the correct result.
The newer specification, XEP-0203 (Delayed Delivery) also says:
[...] MUST be expressed in UTC
I have been using this msn weather api for couple of years now
Programatically access weather info
As of today I get the following error in my app. Access Denied. It could be a glitch or a permanent shutdown by microsoft. I don't know but is there any other free 4 day weather forecast api that I can use to get weather in a XML format? Saddest part is that I have been using this api in at least 20 of my apps and now I am scrambling to find a solution.
I did send an email to weather#microsoft.com couple of hours ago but as predicted no response.
2014-12-10 07:46:40.321 Big Clock[10890:230027] locationStr: http://weather.service.msn.com/data.aspx?weadegreetype=F&culture=en-US&weasearchstr=Detroit,MI
2014-12-10 07:46:40.461 Big Clock[10890:230027] XML:
<?xml version="1.0" encoding="utf-8"?><weatherdata xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><weather errormessage="Access denied: Please contact weather#microsoft.com if you need access to this API." /></weatherdata>
You are not alone in this.
For the time being, passing an additional query string "&src=outlook" worked for me.
Sample Working URL:
http://weather.service.msn.com/data.aspx?weasearchstr=45236&culture=en-US&weadegreetype=F&src=outlook
Try it out and see if it solves your issue.
This is Ram from Microsoft. The existing service will be deprecated soon.
Please resend your email to the alias one more time so we can take it offline. We had an email hiccup so the alias should work now.
Please do not use the outlook as src value.
We are writing to notify you that the Microsoft Weather API will no longer be available for download and will be discontinued as of April 15, 2015, meaning it will no longer provide weather data. Accordingly, please remove the Microsoft Weather API from any of your products or apps that currently use it.
Here is a list of external providers who might be able to support your needs if you are interested in obtaining an alternate weather API:
http://api.accuweather.com/
http://www.wunderground.com/weather/api/d/pricing.html?MR=1
https://developer.forecast.io/
Disclaimer: Microsoft and Microsoft Weather are not affiliated or associated with any of the above companies in any way.
Thank You
Microsoft Weather Team
Thanks to Ram we now know that MSN weather api will be gone by April 15th, 2015.
If anyone wants a free weather alternate then try this
http://openweathermap.org/price_detailes
Calls per minute (no more than) 3,000
Calls per day (no more than) 4,000,000
This is the most I have seen any weather provide give out for free. I hope it helps.
Our experiments have shown that GMail does not use UTC for the internal dates in its mailstore. Anyone know what offset it uses? We've narrowed it to between 3 and 7 hours behind UTC (exclusive), and we could figure it out with further experimentation, but maybe someone knows off-hand. UID SEARCH and the like aren't very accurate if you are assuming UTC and it's not the case. :-)
Further, we're wondering if it's consistent regardless of where you're connecting to gmail in the world.
Update: the first test showed UTC-4 or UTC-5, and a second test I did (sending hourly emails) revealed my account to be UTC-7. We're wondering if it's set when you register depending on your source IP (I also registered an account with a UTC-10 timezone and the internal store was still UTC-7. And changing your account timezone later doesn't change the internal store date an IMAP client sees, wisely, I would think).
I had written a python IMAP lib client and confirmed that the Gmail timezone is UTC-07:00 and I have confirmed it over and over again. So, any search results that you obtain (more precisely the after: startDate and before: endDate query) are shifted by that much amount according to your local timezone. This is because the mailstore uses the local time according to the sender SMTP server, which in case of gmail happens to be at UTC-07:00.