1
votes

I'm sending LUIS a query that is based on a time value (e.g. "what is the time 10 minutes from now" - just an example). I want the time to come back in the local timezone, so on the LuisPredictionOptions object (C#) I set the TimezoneOffset (as an example I set it to 2 hours ahead, or 120 minutes).

In Fiddler I can see when it calls the LUIS endpoint it's correctly adding "timezoneOffset=120.0".

However, the timezone comes back as UTC - it doesn't matter whether the timezoneOffset is set, or even what it is set to, the time always comes back UTC, using the builtin datetimeV2 entity.

Does anyone know what the TimezoneOffset property is for? Am I just using it incorrectly? Is there another way perhaps to get a local time from LUIS?

[Update]: Here are some examples: https://westus.api.cognitive.microsoft.com/luis/v2.0/apps/[AppId]?verbose=true&timezoneOffset=0&subscription-key=[subscriptionkey]&q=/luis/v2.0/apps/c1be57f4-3850-489e-8266-db376b82c011?timezoneOffset=120&log=true

https://westus.api.cognitive.microsoft.com/luis/v2.0/apps/[AppId]?verbose=true&timezoneOffset=0&subscription-key=[subscriptionkey]&q=/luis/v2.0/apps/c1be57f4-3850-489e-8266-db376b82c011?timezoneOffset=240&log=true

and I'm trying the following example utterance: "in 10 minutes".

When I do this, the timex is in UTC (e.g. timex=2020-01-11T16:08:25) and the "value" comes back with the same value, minus the "T", as follows: value=2020-01-11 16:08:25

I could understand perhaps if the timex is in UTC, but then possibly "value" should be adjusted by the timezoneOffset?

2
I think you pasted the wrong value as your queries in those sample URL's - Kyle Delaney
Thanks Kyle - I got this figured out though - see my comment below. I was doing some manual testing and indeed got these URLs messed up, but it was part of a wider problem figure out some time issues which I eventually came right with. - Hilton Giesenow
Are you going to accept Hazem's answer then? - Kyle Delaney
Well, he wasn't totally correct about the url, and certainly it had nothing to do with the SDK version, so wasn't sure it was a 100% "accept". He certainly helped me find the right direction though, which is why I upvoted his answer. That make sense? - Hilton Giesenow
You didn't provide enough information to discover the actual problem, so given the question you asked he was as correct as he possibly could have been. But if you're not going to politely accept his answer then you should post your own answer so you can accept that. - Kyle Delaney

2 Answers

1
votes

It looks like there's an incorrect question mark in your URL, right before timezoneOffset.

Using the same query I was able to get the expected behavior, where the returned value is different by 10 minutes.

Which SDK are you using? Perhaps you're using the V3 Runtime SDK which uses the V3 endpoint that doesn't use timeZoneOffset but instead uses datetimeReference, and need to use the V2 Runtime SDK instead.

https://westus.api.cognitive.microsoft.com/luis/v2.0/apps/[app-id]?verbose=true&timezoneOffset=10&subscription-key=[key]&q=in 10 minutes

0
votes

The TimeZoneInfo class's FindSystemTimeZoneById method can be used to determine the correct timezoneOffset based on system time. An example in C# is shown below:

// Get CST zone id
TimeZoneInfo targetZone = TimeZoneInfo.FindSystemTimeZoneById("Central Standard Time");

// Get local machine's value of Now
DateTime utcDatetime = DateTime.UtcNow;

// Get Central Standard Time value of Now
DateTime cstDatetime = TimeZoneInfo.ConvertTimeFromUtc(utcDatetime, targetZone);

// Find timezoneOffset
int timezoneOffset = (int)((cstDatetime - utcDatetime).TotalMinutes);

Reference: https://docs.microsoft.com/en-us/azure/cognitive-services/luis/luis-concept-data-alteration?tabs=V2#c-code-determines-correct-value-of-timezoneoffset