Timezone-aware termination times?

Identity Security Cloud (ISC) ISC Discussion and Questions
, ,
1

Hello!

I need to apply a timezone offset to the worker’s termination date so that we can process terminations at a specified time in the worker’s local timezone. However, it doesn’t look like we can reference a variable in the dateMath primitive’s expression field, so I’m at a bit of an impasse.

Ideally, I’d be able to use the dateTool Velocity function in a static transform to handle this, but it doesn’t look like that functionality has been added yet.

So far, the best solution I’ve been able to come up with is a static transform that combines the term date with the offset (which unfortunately requires a lookup table to convert the offset in hours to the properly-formatted string value; eg +5.5 to +5:30).

{
    "name": "terminationTime",
    "type": "dateFormat",
    "attributes": {
        "inputFormat": "MM/dd/yyyy'T'HH:mm:ssX",
        "outputFormat": "ISO8601",
        "input": {
            "type": "static",
            "attributes": {
                "termDate": {
                    "type": "firstValid",
                    "attributes": {
                        "ignoreErrors": "true",
                        "values": [
                            {
                                "attributes": {
                                    "sourceName": "Workday",
                                    "attributeName": "LAST_DAY_OF_WORK"
                                },
                                "type": "accountAttribute"
                            },
                            {
                                "type": "static",
                                "attributes": {
                                    "value": "01/01/2100"
                                }
                            }
                        ]
                    }
                },
                "offset": {
                    "attributes": {
                        "table": {
                            "0": "-0000",
                            "1": "+0100",
                            "8": "+0800",
                            "-5": "-0500",
                            "-6": "-0600",
                            "-8": "-0800",
                            "5.5": "+0530",
                            "default": "-0000"
                        },
                        "input": {
                            "attributes": {
                                "sourceName": "Workday",
                                "attributeName": "Workday_Timezone__c"
                            },
                            "type": "accountAttribute"
                        }
                    },
                    "type": "lookup"
                },
                "value": "${termDate}T23:59:59$offset"
            }
        }
    },
    "internal": false
}

Any other ideas about how to handle this?

2
  • You can use a join transform instead of building the string manually.
  • Make sure your timezone lookup table covers all cases.
4

Thanks @Chaithu9110.

If you’re referring to the concat primitive when you say “join transform,” that’s effectively the same as what I’m doing with the static, no meaningful difference there.

As for the lookup table, I’ve included all the timezones currently needed. The default case covers situations where the timezone offset is not otherwise listed.

5

Are you sure you can’t use a transform to build the expression attribute for the dateMath transform? From my experience, any string value within a transform’s attributes can also be defined using a velocity string or another transform.

6

You can do something like this:
image

Date (without time) to epoch → First number
86399000 is the 23:59:59
Then just add the (string [of Workday_Timezone__c] to double) times 3600000, this gives you the offset in epoch milli.

Here, I’m using a static ‘-5.5’ string, but in your case, you just need to pass in a string variable…be it “8” or “-12”

Then from the epoch, date format it back to a string / value that you need (e.g. ISO8601).

Edit: Think I missed the -1 (i.e. -1 x timezone offset x 3600000, to get the epoch back to UTC)