I have an IDM driver syncing Lockout events from AD to eDir and eDir to
AD. Basically out of the box policies.

So the policies decide that you cleared lockout in eDir to clear it in
AD, by seeing a time value set to 0.

But SSPR seems consistently setting it to 3661. Which is 1 hour, 1
minute, and 1 second into Jan 1, 1970 in CTIME? (Is this some sort of
bizarre Rememberance Day joke? 11th hour or 11th month, etc? if so,
classy! If not, meh)

Why? Why 3661? Is this always going to be the case?

(As in, I can easily modify the policy to treat 3661 as 0, or actually
any value less than NOW in CTIME, but all that is meaningless if there
is a reason and it changes without my understanding why).

Here is an example of the event it sent:

[06/12/15 13:37:50.307]:AD ST:
<nds dtdversion="4.0" ndsversion="8.x">
<product edition="Advanced" version="">DirXML</product>
<contact>NetIQ Corporation</contact>
<modify cached-time="20150612173750.074Z" class-name="User"
state="associated">3159dae838a73a47a97263812d47784 2</association>
<modify-attr attr-name="lockoutTime">
<value timestamp="1434130261#13" type="time">1434132061</value>
<value timestamp="1434130665#14" type="time">3661</value>

User IS unlocked, but the way the IDM driver works, it maps the Login
Intruder Reset Time to intruderLockout in AD, which are both time based.
So SSPR is clearly resetting the Locked By Intruder attr (good!) but
setting 3661 in this attr is odd.