Microsoft Graph - FindMeetingTimes API error? - microsoft-graph-api

I am seeing issues with the Graph API method findMeetingTimes.
As you can see from the attached file the API response differs depending on the start time. When using flat times like 12:00 the response includes only flat times - while when using non-flat times like 12:15 it only includes 'half-hour times'.
)
So to get all possible meeting times I would have to make at least two API calls, which doesn't seem very practical.
Is there something I am missing ?
Thanks in advance,
Jacky

No, you are not missing anything. You'll need to call the API more than once to get suggestions with overlapping times.
The API returns the nearest available time to the start time specified in the request. The suggestions will always be on the hour or at half past.
Thereafter, it will give suggestions with increments of 30 minutes, or value specified in the meetingDuration property from the first suggestion, without overlaps.
If you had set your start time to say, 12:15 and the first available time is 13:00 and meeting duration is 1h, all suggestions will be on the hour. The same applies if you'd set the start time to 12:00 and the first available time is at 12:30, all suggestions will be at half past.
You can add the returnSuggestionReasons property in your request which gives an explanation on why a particular time was suggested.
{
"timeConstraint": {
"activityDomain": "unrestricted",
"timeSlots": [
{
"start": {
"dateTime": "2021-05-24T12:00:00",
"timeZone": "UTC"
},
"end": {
"dateTime": "2021-05-24T18:00:00",
"timeZone": "UTC"
}
}
]
},
"meetingDuration": "PT30MIN",
"returnSuggestionReasons": "true"
}

Related

How to know if a user can book a room on Office 365 from graph api

Is it possible to know if a user has the right to book a meeting room with the Graph API?
I need to book rooms from my backend. Today, if the user does not have the right to book the room, he receives a rejection email.
I would like to check his authorization before booking from the graph api.
At least you can call getSchedule endpoint to get the free/busy availability information for a collection of users, distributions lists, or resources (rooms or equipment) for a specified time period.
POST https://graph.microsoft.com/v1.0/me/calendar/getSchedule
In request body specify the rooms you want to book and the date, time, and time zone that the period starts and ends.
{
"schedules": [
"MeetingRoom534#xxx.com",
"MeetingRoom535#xxx.com"
],
"startTime": {
"dateTime": "2022-06-02T01:00:00",
"timeZone": "Central Europe Standard Time"
},
"endTime": {
"dateTime": "2022-06-02T18:00:00",
"timeZone": "Central Europe Standard Time"
},
"availabilityViewInterval": 60
}
The response will contain a collection of scheduleInformation.

Searchkick: Boosting future dates

I'm using Searchkick in a Rails project with an ElasticSearch 6.8 server. I'm trying to boost certain documents that have a year field that's equal to this year or a year in the future.
I've tried using boost_where and most recently boost_by but neither work. boost_by generates a function_score function that errors out in ElasticSearch. Here's my most recent try.
Model.search('value', boost_by: { year: { scale: '5y' } })
ElasticSearch seems to dislike the calendar interval (5y) even though this should be valid. Here's the reason object from the error:
"caused_by": {
"type": "number_format_exception",
"reason": "For input string: \"5y\""
}
I've tried setting origin and decay along with scale but that doesn't seem to help anything.
Here is the query generated by Searchkick (model and field names changed due to a very specific domain model).
Model Search (163.5ms) model_development/_search {"query":{"function_score":{"functions":[{"weight":1,"gauss":{"year":{"scale":"5y"}}}],"query":{"bool":{"should":[{"dis_max":{"queries":[{"multi_match":{"query":"Abreu","boost":10,"operator":"and","analyzer":"searchkick_search","fields":["*.analyzed"],"type":"best_fields"}},{"multi_match":{"query":"Abreu","boost":10,"operator":"and","analyzer":"searchkick_search2","fields":["*.analyzed"],"type":"best_fields"}},{"multi_match":{"query":"Abreu","boost":1,"operator":"and","analyzer":"searchkick_search","fuzziness":1,"prefix_length":0,"max_expansions":3,"fuzzy_transpositions":true,"fields":["*.analyzed"],"type":"best_fields"}},{"multi_match":{"query":"Abreu","boost":1,"operator":"and","analyzer":"searchkick_search2","fuzziness":1,"prefix_length":0,"max_expansions":3,"fuzzy_transpositions":true,"fields":["*.analyzed"],"type":"best_fields"}}]}}]}},"score_mode":"sum"}},"timeout":"11s","_source":false,"size":10000}
Year is likely not a supported date format due to it not having an absolute representation. One day is always 24 hours, but one year is sometimes 364 days and usually 365 days. Rather than solve for this complexity, ES likely stops at days.
If you want, you can instead use days for your scale:
Model.search('value', boost_by: { year: { scale: '1825d' } })

Change Amazon Lex Chat bot Time zone

Now,I am integrating my amazon Lex chat bot to my web. I got the time zone issue. Time zone is in US East (N. Virginia). So if I say today, that is based on Virginia time. So I find how to change time zone and the suggestion is to set the x-amz-lex:time-zone request attribute to my region. but I donot know how to do and where to do. PLs help me!! Thanks.
I used simple Template "https://s3.amazonaws.com/aws-bigdata-blog/artifacts/aws-lex-web-ui/artifacts/templates/master.yaml".
I copied the codes from SnippetUrl and paste to my web page. The Chat Bot appear. So how should I pass these request attribute.
this this my chat bot in amazon lex
this is my cloud formation
These codes are from SnippetUrl in CodeBuildDeploy
There may be an option in the template you are using but I can't find it, so here is what you need to know about setting timezones in Lex.
First of all, the only way to change the timezone from the default East US is to use PostContent API or PostText API. They should really have a timezone setting in the Lex Console so you can set the default timezone at least, but they don't.
The correct way:
The AWS SDK is needed to use PostContent API or PostText API to pass the user's input to your Lex chat bot. When passing data to Lex this way, you can include requestAttributes with the user's input, unique ID and session attributes (optional). Here's an example of how you would set the timezone in requestAttributes to Singapore Time:
{
"inputText": "What the user said.",
"requestAttributes": {
"x-amz-lex:time-zone" : "Singapore"
},
"sessionAttributes": null
}
The workaround:
If you cannot use or cannot access the use of PostContent or PostText, then you need to work with what you have. Right now, it looks like you are only using a Lambda function for fulfillment, but you should really also use it for "initialization and validation" too.
This will pass a request to your Lambda function every time Lex processes an input and you can direct Lex with exactly how to reply. This gives you much greater control of your chat bot.
To understand the format of the Request (sometimes called "Event") and how to format the Response in that Lambda function, you will want to read these docs.
Now, Lex processes the date and time from the user's input...(In your example, the user says "today")...and Lex will fill the date or time slots with something like (date) 2018-11-02 (time) 13:00 which will be appropriate for Eastern Standard Time (UTC -5). But Singapore is UTC +8. So you will need to convert that date and time in your Lambda function and overwrite the slots to the equivalent Singaporean time then pass those slots back in your Lambda's response to Lex.
There are multiple ways to do that conversion depending on whether your Lambda is in Node.js or Python and plenty of answers and guides on timezone conversion.
Example:
User Input: "I want to book a meeting room from 1pm to 2pm for today"
To capture the values of this input, your Intent should be set up with something like:
3 slots: {date} {time_start} {time_end}
Intent Utterance: "I want to book a meeting room from {time_start} to {time_end} for {date}"
Lex will then parse the input and fill the slots (using timezone default: East US). Then Lex will pass the request to your "initialization and validation" Lambda Function. The request (or "event") will include:
{
"currentIntent": {
"name": "BookRoom",
"slots": {
"date": "2018-11-05",
"time_start": "13:00",
"time_end": "14:00",
},
},
...
}
Then in the Lambda Function you can take those values (Node.js):
var date = event['currentIntent']['slots']['date'];
var time_start = event['currentIntent']['slots']['time_start'];
var time_end = event['currentIntent']['slots']['time_end'];
Now for your conversion logic:
Since Singapore is 13 hours ahead of East US, just take those times and add 13 hours to them. If when doing that, it passes midnight, then also increase the date by 1 day.
This will work for inputs of "today", "tomorrow", "next tuesday", or even "25 Jan 2035", because Lex parses all of those the same way and simply delivers them to your Lambda in default East US time formatted as (date) yyyy-mm-dd and (time) hh:mm.
After you convert them, just set those slots as the new date and times, then pass the slots back to Lex in your response. Lex will then hold the slot values in Singapore time.
This is the solution image
Finally, I got the solution. If someone want to know the solution check in the photo. I just try to fix the codes from aws github. Thanks.

How ot write points into influxdb 0.8 with time in seconds

I would like to write points into an influx 0.8 database with the time values given in seconds through HTTP. Here's a sample point in JSON format:
[
{
"points": [
[
1435692857.0,
897
]
],
"name": "some_series",
"columns": [
"time",
"value"
]
}
]
The documentation is unclear what the format of time values should be (nano or milli seconds?) and how to specify to influxdb what to expect. Currently I'm using a query parameter: precision=s
That seems to work fine, the server returns HTTP Status code 200 as expected. When querying against the database using influx' admin interface using select * from some_series the datapoints in the table are returned with the expected timestamp. On the graph however, the time axis is indexed with fractions of seconds and queries like select * from some_series where time > now() - 1h dont yield any results.
I assume that there is something wrong with the timestamps. I tried multiplying my value by 1000 but then nothing gets inserted into the database with no visible errors.
Whats the problem?
By default, supplied timestamps are assumed to be in milliseconds. I think your writes are defaulting to milliseconds because the query string parameter should be time_precision=s, not precision=s.
See the details under "Time Precision on Written Data" on https://influxdb.com/docs/v0.8/api/reading_and_writing_data.html.
I also think the time value should be an integer rather than a float. I'm not sure how to explain the other behaviors, where the timestamp seems to be the right date and multiplying by 1000 doesn't solve the issue, but I wonder if it's related to writing floats.
Please contact the InfluxDB support team at support#influxdb.com for further assistance.
I found the solution! The problem was only in part with the precision. Your answer was correct, the query parameter is called time_precision and I should post integers instead of floats. Which was probably the first thing I attempted with no results...
However, due to some time zone problems, my time values where in the future relative to server time and by default, any select statement includes a where time < now() statement. So, in fact values were written into the database, but not displayed because of that hidden where statement. The solution was to tell the database to return "future" values, too:
select value from some_series where time < now() + 1h

Google timezone API - timestamp parameter

In my client application I have the Latitude & longitude information from skyhook API based on its I.P.
Now based on the latitude and longitude information I need to find out the timezone information of the client. But in the google timezone API documentation https://developers.google.com/maps/documentation/timezone/ I see that timestamp is a mandatory field. In which case what should I need to do.
Also can you kindly help me understand what does the timestamp corresponds to? For e.g :- If my Application server is in U.S.A (say PST timezone) and it makes the google API call passing the server timestamp.
If user logs into client application from India passing lat / long information, to the app server to get the timezone information what will the API provide as dstOffset and rawOffset? i.e If I add the server timestamp with dstOffset and rawOffset will I be getting the client machine timezone information?
I've been scratching my head on Google's Timezone API for a few minutes, specifically on the timestamp parameter. Maybe this will lay out the need:
In San Diego, we (now, in August) have a GMT offset of -8 because of daylight savings time. However, in November we'll have a GMT offset of -7.
So which gmt offset should Google return? -7 or -8? They're both valid, but it depends on what day you take the measurement.
Enter the Timestamp argument. Running the service now, and using a timestamp value of August 2015, I get this response:
{
"dstOffset" : 3600,
"rawOffset" : -28800,
"status" : "OK",
"timeZoneId" : "America/Los_Angeles",
"timeZoneName" : "Pacific Daylight Time"
}
But if I bump the timestamp to November 2015 (once San Diego is out of daylight savings, I end up with this):
{
"dstOffset" : 0,
"rawOffset" : -28800,
"status" : "OK",
"timeZoneId" : "America/Los_Angeles",
"timeZoneName" : "Pacific Standard Time"
}
In both cases the rawOffset is the same, but the DST changed because of the timestamp I provided. If you just want to know the raw timezone, the timestamp doesn't matter.
But if you want an application to reliably do something at 8:00am in San Diego in August and 8:00am in November in San Diego, you'll need to engage the timestamp.
Putting it another way, what's the value of knowing that San Diego is normally -7 hours offset from GMT. If you're working with timezones, you're likely trying to ensure that your UTC time is matched up with what a real person in that location is experiencing. As such, the DST offset is critical.
The documentation link you provided clearly states that the timestamp should be in UTC and that it is used to show the correct DST offset value. It will also control if the timeZoneName field is shown with "Standard" or "Daylight" in the name.
If you don't care about that and just want the timeZoneId field, then it doesn't matter what value you pass.
Try this
DateDiff("s", "1/1/1970", DateTime.Now)

Resources