Azure SCIM User Provision sending invalid time zone information for date fields

Egor Kolesnikov 0

Depending on user time zone, fields like "employeeHireDate" are either stored or sent with invalid time zone over SCIM endpoint. Are there any settings in Entra ID to either enforce correct time zones or drop time portions for Date fields completely?

Context:

AD field employeeHireDate is mapped to extension joinDate field in target system.

Actual behaviour:

Me (European TZ, GMT+2) setting up employeeHireDate to "15 November 2023" in Entra ID UI

PatchOp:

{
  "Operations" : [ {
    "op" : "replace",
    "path" : "urn:ietf:params:scim:schemas:extension:acea:2.0:User:joinDate",
    "value" : "2023-11-14T22:00:00Z"
  } ]
}

Colleague (US TZ, GMT-5) setting up employeeHireDate to "15 November 2023"

PatchOp:

{
  "Operations" : [ {
    "op" : "replace",
    "path" : "urn:ietf:params:scim:schemas:extension:acea:2.0:User:joinDate",
    "value" : "2023-11-15T05:00:00Z"
  } ]
}

Both requests are coming through with invalid GMT+0 (Z) timezone which leads to incorrect behaviour in the target system.

Expected results:

PatchOp contains "2023-11-14T22:00:00+02:00" when value is changed by the EU user

PatchOp contains "2023-11-15T05:00:00-05:00" when value is changed by the US user

JamesTran-MSFT 36,501 Reputation points Microsoft Employee

2023-11-20T18:07:20.3533333+00:00

@Egor Kolesnikov

I wanted to check in and see if you had any other questions or if you were able to resolve this issue?

If you have any other questions, please let me know. Thank you for your time and patience throughout this issue.

If the information helped address your question, please Accept the answer. This will help us and also improve searchability for others in the community who might be researching similar information.
Egor Kolesnikov 0 Reputation points

2023-11-21T11:08:50.92+00:00

Hi James - if you're happy with "This is Entra bug, deal with it" resolution, I'm happy to accept Danny's answer, otherwise would like to keep it open while he's working on it.

1 answer

Danny Zollner 9,536 Reputation points Microsoft Employee

2023-11-13T17:46:03.7866667+00:00

And this is the problem with using localized time zones in applications :) Using UTC across the board solves this..

Anyways, you're likely looking for this function: https://learn.microsoft.com/en-us/entra/identity/app-provisioning/functions-for-customizing-application-data#formatdatetime

You can use the formatDateTime function to define the formatting and drop the time portion, leaving only the date.
Please sign in to rate this answer.
Egor Kolesnikov 0 Reputation points

2023-11-13T18:29:13.9033333+00:00

There are no problems with localised time zones. The problem is Entra adjusting time whilst assuming UTC.

Nevertheless, I'm quite befuddled:

FormatDateTime

Function: FormatDateTime(source, dateTimeStyles, inputFormat, outputFormat)

Description: Takes a date string from one format and converts it into a different format.

Since [employeeHireDate] is DateTime type, how is FormatDateType even relevant here?

ps: if your solution implies simply dropping time portion, it won't work as the date will be different in GMT-negative time zones

Danny Zollner 9,536 Reputation points Microsoft Employee

2023-11-13T18:52:52.6833333+00:00

Ah - yeah, I think I get what you're saying - part of the problem didn't click in my mind immediately, sorry. I've still got my own opinions on everything just thinking in UTC natively and handling date/time conversion locally, but my opinion doesn't count for any more than anyone else's..

A few questions to try to figure out what's going on - you're using the employeeHireDate as your source attribute..

What's the original/source value in employeehireDate in one of these examples?

Is the mapping direct, or is it an expression with one or more functions that are manipulating the value to handle applying the time zone offset?

Egor Kolesnikov 0 Reputation points

2023-11-14T06:19:59.37+00:00

Ah, we're on the same page here - our app does store everything in UTC internally, thankfully we're not dealing with moving things across different time zones for that to become a problem.

Now to answer your question: 15 November 2023 is the original value which we set up in Azure EntraID UI (see the screenshot attached). It has direct mapping to urn:ietf:params:scim:schemas:extension:acea:2.0:User:joinDate field in provisioning.

The issue is that when I save this user in my local GMT+2 time zone, [employeeHireDate] comes back as "14 Nov 2023 22:00:00 GMT" during provisioning. When my colleague in California (GMT-5) saves this same object using the same Azure/EntraID UI, the field comes back as "15 Nov 2023 05:00:00 GMT". It feels like something in Azure UI takes localised time from the browser, applies correct time zone offset to what I believe is the actual value of "15 Nov 2023 00:00:00 GMT" and then erases the time zone information, pretending it to be GMT time, which it is clearly not.

I'd be much happier if it either stops applying offsets at all, so the date always comes back as "15 Nov 2023 00:00:00 GMT" no matter who/where edited it, or keep TZ information so it comes back as "2023-11-14T22:00:00+02:00" after my edits / "2023-11-15T05:00:00-05:00" after my colleague's.

Danny Zollner 9,536 Reputation points Microsoft Employee

2023-11-16T18:25:26.1066667+00:00

Just dropping a note that I'm looking into this - have a conversation going with one of my colleagues who is responsible for the UI in question, which appears to be the component that is applying the offset.

Egor Kolesnikov 0 Reputation points

2023-11-17T10:29:07.1466667+00:00

Hi Danny

Thanks a lot for the heads-up, in the meantime we just save this field as is into separate data to prevent bogus patch on each sync, and "round-up" offset data as we don't really expect it to be anything but 00:00 there

Danny Zollner 9,536 Reputation points Microsoft Employee

2023-11-27T19:24:01.3933333+00:00

Haven't heard anything final on this yet. To reference your above comment on the question (not in this thread), I don't think I can 100% confidently classify this as a bug quite yet. Waiting to get the final determination from the team that owns this.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Azure SCIM User Provision sending invalid time zone information for date fields

1 answer

Your answer