Sometimes FIM strikes me as being way to clever for its own (and usually my) good – and I’ve been looking into a problem for a client that ticks this box big time.
They have a number of email notifications that they need to generate that instruct various parties within the organization about people joining, moving and leaving so that the processes that they can’t or don’t want to automate can be initiated based on the data held by FIM – in this scenario, a leavers email is sent to HR letting them know when a contractor has reached their leaving date.
This works fairly well for six months out of every year – during the daylight savings months, the email is issued the day before its supposed to go out, and the HR department being highly efficient are carrying out the required action when they see the email leading to all sorts of downstream mayhem trying to clean up after the event.
Naturally, focus fell on a custom workflow that is used to generate these emails and after spending an amount of time pulling apart the code it occurred to me that nothing in the workflow could actually be causing this and it was the user account transitioning into the temporal set that was executing a day early (obvious in hindsight 
) – seeing as I had visual studio hooked up to the workflow, I moved a few more users about and it turned out that even though their leaving date was set correctly – e..g 03/06/2015 – FIM was transposing this in the background and storing it as 02/06/2015 23:00.
What it appears is that when FIM is presented with a date, it’s transposing it into UTC for internal storage and as during June GMT (the configured time zone for the solution) is +1 hour compared to UTC, it’s removing the hour and bringing the user’s leaving date forward into the previous day – allowing it to trigger the removal notification effectively 24 hours early.
Fortunately as FIM is using its configured time zone to work this out, it’s a fairly simple case (in this instance!) to create a new UTC TimeZone object and then configure FIM to use this instead of the previous GMT one although this probably isn’t going to be a fix in all instances!
