I’ve been confusing myself no end with temporal set rules and I’ve finally figured out it’s because I thought “today” meant what it sounds like – whereas in fact it means “now”.
So “1 day from today” means “this time tomorrow” and “1 day prior to today” means “this time yesterday”.
This is very relevant when you have rules that do things like disable an account the day after the listed end date. Your transition set may have a rule like this:
“EmployeeEndDate prior to today”
This sounds clear enough – if the EmployeeEndDate is yesterday or earlier then transition in to the set and trigger the appropriate workflows. However the reality may be different with some accounts getting disabled on the end date, rather than waiting until the next day.
By default the FIMTemporalEventsJob runs in SQL at 1am. If the user’s EmployeeEndDate is set to today’s date with a timestamp of “12:00:00 AM” this time is actually in the past when the 1am job runs, so the account gets disabled. Conversely if the timestamp was something like “8:00:00 AM” that time would still be in the future and the account would not get disabled until the following day – even though in both cases the date part is the same and we should be able to expect the same behaviour.
The most important thing to do is get all timestamps set to a consistent “12:00:00 AM” local time wherever the date is of interest but we don’t care about the time. Controlling data entry points is a big part of it. The FIM RCDC forms will append “12:00:00 AM” when only the date is entered – but there’s no way to stop someone entering a timestamp as well. Scripts can help but you need to hardcode the XPath filter with specific dates – I have some data quality tasks that check particular date attributes up to 20 days in the future (one day at a time) looking for incorrect timestamps and normalising them. It’s not pretty, but seems to be necessary.
