1. UNIFYBroker Forum
  2. Questions
0
Answered

Use case for the time offset transformation

Bob Bradley 11 years ago • updated by anonymous 8 years ago • 3

I have a source date property for BirthDate which is appearing in the format CCYY-MM-DD, and when this is imported to FIM it is being treated as UTC time and is consequently shown with a local date/time offset value (i.e. + 10 hours in Sydney). I therefore need to find a way of subtracting the local time offset from the base value.

I have looked at the doco for this transformation https://unifysolutions.jira.com/wiki/display/IDB307/Time+offset+transformation and it appears to only cater for the reverse scenario - i.e. converting UTC to local. Is there a way to use this (or any other transformation) to subtract the local time from the base value?

Thanks.

Adam van Vliet 11 years ago

What do you mean by "only cater for the reverse scenario - i.e. converting UTC to local"? A date has no time information, so it really depends on whether the transformation can cater for a date data type, which from the Inputs section it sounds like it does.

Did you try something like the following?

<adapterEntityTransformationFactory
    name="TimeOffset"
    SourceColumn="BirthDate"
    DestinationColumn="BirthDateAdj"
    Offset="-10:00:00"/>
Bob Bradley 11 years ago

The raw data contains no time component, but the FIM attribute which is being loaded by the FIM sync service does - hence on import we start off with a raw date 01/01/1980 and end up with 01/01/1990 10:00 AM. We are transitioning from one HR system (already FIM-connected) to another, and now that the data has been migrated I am looking for zero changes in DOB. However every single employee is showing up as a (bogus) change (adding 10 hours).
I thought of trying the hard-wired offset of -10 (i.e. a negative number) but I thought I'd better first check to see if there was anything which was the reverse of the "AdjustForLocal" parameter - i.e. I was looking for say a zero Offset value but a "ToUTC" conversion instead. Now you have suggested the above I'll give that a go - problem is that if we run this after Daylight Savings comes in I am going to have to change this value.

Bob Bradley 11 years ago

Thanks Adam van Vliet - will run with this for now since it is working for the moment (you Queenslanders don't have to worry about daylight savings adjustments). What I expect to happen, however, is that when the clocks roll forward an hour we'll see every employee record from PHRIS have their DOB adjusted by 1 hour, and this will happen again when they roll back in Autumn. Of course this would be easily resolved with a rules extension - but this being a FIM declarative rule site this kind of transformation is not supported (and I'm trying to keep all the rules together in the one place). Will alert customer to possibility of the adjustments occurring twice a year - don't expect it will be a big deal though.

Customer support service by UserEcho