We have a requirement that when a user signs a document, we need to set the date of the user, not the system date. We can grab the users's profile timezone to calculate the date, but they are concerned that the user's can alter this to achieve the required date. User's cannot change their system timezone/clock. Is it possible to capture the system clock in SAIL when I user clicks the "Sign" button?
Discussion posts and replies are publicly visible
Remember that no matter what else, you can and should [also] store the GMT date/time value of the signature, so if there's ever some sort of dispute, the system administrators can have an absolute record of the actual time the signature happened, since presumably they'd be able to tell the user's actual timezone rather than whatever they set their in-Appian timezone to.
Sorry I should have been more clear. We want to grab the user's system clock.
I got that. I don't think you can (at least, I don't happen to know a way off the top of my head). Hence why I'm advising you to [also] store some in-system record of the GMT signature date, since users wouldn't be able to fudge that and it could be used as the source of truth when conflict resolution is needed.
Yes, that's a good idea and we are doing that as well. The requirement is for the signature date to go on the legal document so it has to represent what the user was working on and the time they executed their signature.
Like I said above, they are unable to change the date/time of their computers (locked down) but Appian doesn't lock down their profile timezone.
Unless Appian introduces the ability to lock down that user setting in an upcoming version (which I don't believe they will), you'll probably need to take an outside-the-box approach to this - perhaps adding a warning on the SAIL form, or even a checkbox which users need to click before the document is generated, certifying that "the local time displayed here is accurate for my physical location", or some similar boilerplate language.
You could also potentially store individual user timezones for each user if you're keeping a separate DB table of users (which i usually recommend anyway), and in the process you could either just use that as the timestamp offset, or (particularly if your product owners are worried about active attempts at shenanigans), compare that value with the one generated in-process to sniff out any mismatches, in which case a system admin could be alerted or any of a number of other possibilities.