Date/time picker for custom command parameter not working properly

Question

I've had a couple custom commands configured since 6/2023 and they've been working just fine up until recently (sometime within the past few weeks or so). Here's a general overview --

Command 1 allows someone to choose a user, then select the date of their departure and date of return for a leave of absence. These values are stored in AD under their extensionAttributes.

Command 2 allows someone to select a different return date, which updates the stored value in the extensionAttribute.

Both commands are configured to send a confirmation email upon completion.

I then have a daily scheduled task that checks users for those attributes, and if their value matches today's date, executes certain actions against the user.

The issue is that the date/time picker is no longer working as expected for some initiators. It seems like the issue could be caused by something related to timezone, DST, or the leap year -- just based on the timing around when this broke -- but it may be coincidental. Either way, we haven't modified the commands so I'm not sure why the behavior has changed suddenly.

I am in EST, as is the Adaxes server, and the date picker works fine for me. Two of my coworkers in the PST timezone sometimes find that the command is executing as though they picked the following day. For instance, they choose 3/1 but the command executes as though they selected 3/2.

Here's a brief overview of 'Command 2' and an example of this issue occuring for one of our PST based initiators ---

Custom command parameter --

Custom command actions --

Snip from email notification code --

Date picker --

Execution log --

Snip from confirmation email --

Not sure if we're missing something obvious here. But I can't make sense of why this is suddenly an issue.

Answer 1

This was resolved by removing %extensionAttribute15% as the default value of the command parameter.

Answer 2

Hello,

The behavior is expected and is related to the differences in time zones between the computers where the Web interface is accessed and the computer where Adaxes service runs. We are not familiar with your environment and thus cannot tell for sure why the behavior started only now (seems to be after the time zones switch to daylight). Unfortunately, there is no solution to make the configuration you have work as expected. The only approach that we can suggest is storing the dates in the extension attribute in UTC time zone and replace the two current actions with a script. The script will save the date in UTC to the attribute and send the email with the date in UTC time zone as well.

Comments

Well .. not the response I was hoping for.

To complicate things further, I created a test command with a date picker that simply triggers an email containing the following --

date/time selection -- 
%param-datetime%

date/time set for 00:00 (exattrib15) --
%param-datetime,,00:00%

date/time m/d/yyy (email notification)--
%param-datetime:format[M/d/yyyy]% 

These are the same values I use in the actual command which you can see in my earlier screenshot. When one of our PST initiators runs the command and chooses a date, say 3/25, this is the email we receive --

Which is correct.

The lack of consistency is puzzling and seems indicative of some issue rather than being "expected" based on timezone or DST.

---

Hello,

There is no issue and the behavior in your last example does not differ from the one in the initial request. It is just that the time is set so that it does not switch to another day according to time zones.

---

There is no issue and the behavior in your last example does not differ from the one in the initial request.

Huh? The behavior is different. When running the actual command, the initiator chooses a day (4/8) but the date changes to (4/9).

In the test command, the initiator chooses 3/25 and the date stays 3/25.

Both commands are using a date/time picker to set a parameter and are then taking that parameter and formatting it as follows

%param-datetime,,00:00%

%param-datetime:format[M/d/yyyy]% 

But the value of the parameter is being interpreted differently by Adaxes.

It is just that the time is set so that it does not switch to another day according to time zones.

What do you mean by this?

...

The same initiator tried executing the actual command against a user again yesterday.

The proper date selection was 3/20, but because of the issue, he selected 3/19 expecting the date to skip ahead to 3/20. Instead, the date was set at 3/19.

He submitted the form again with the date selected as 3/20, and it skipped ahead to 3/21.

So it's not even consistent.

The commands were run 1 minute apart at 2:20 PM and 2:21 PM PST and I wouldn't expect a timezone difference of +- 3 hours, or a DST difference of +- 1 hour, to make a difference at that time of day.

---

Hello,

But the value of the parameter is being interpreted differently by Adaxes.

The custom command parameter settings are different and that is why you think that the behavior is somehow different. In the initial custom command you referenced, it impossible for the time to be 4:07.00 PM. It will always be 12:00:00 AM. And that is the core difference.

The proper date selection was 3/20, but because of the issue, he selected 3/19 expecting the date to skip ahead to 3/20. Instead, the date was set at 3/19.

As we supposed in the initial replay, your Adaxes service is installed in the EDT (UTC -4) time zone. At the same time, the user signing in in to the Web interface is in the PDT (UTC -7) time zone. That gives us a 3 hour difference.