For a long time, the AD driver has shipped with default rules (Still
basically the same in IDM 4 packaged versions) for converting some AD
attrs from FILETIME (64 bit int with a count of 100 nanosecond intervals
since 1601) to eDir's CTIME (32 int, count of seconds since 1970) with
an XPATH call of something like this:

jadutil:translateFileTime2Epoch($current-value)

Now this works fine if you run through a normal value. But when you
get a null value or a zero value, it returns a strange value that makes
no sense in the context of CTIME.

So send in lockoutTime of 0 and you get a CTIME of 4294967295 which
makes little sense in CTIME. Since that is technically:
Sun, 07 Feb 2106 06:28:15 GMT

I have modified the rule to wrap the reformat op-attr with an if op-attr
is changing to zero to clear the value in eDir.

Same issue with accountExpires (which is a bit worse, since the AD
picker shows a date not a time, and there is some goofy rounding issue
going on there, so you might loose a day or gain a day due to rounding.

Seems like it would be simpler to just fix the class, to properly handle
zero as expected.