Working with MS's Integer8/LargeInteger in Java?

I am working with AD via LDAP (using Spring LDAP) and I ran into a odd problem while working with Integer8/LargeInteger being used as timestamps which are outlined here. Namely, my attempts to write to fields of that type have resulted in...

Malformed 'field name here' attribute value

I've tried putting Longs and Strings in hopes that the underlying implementation would do any needed conversions but no luck. Here is how I am doing my math...

/* AD Keeps track of time in 100 NS intervals (UTC) since Jan 1st 1601 */
long   winEpocMS    = new GregorianCalendar(1601, Calendar.JANUARY, 1).getTimeInMillis();        
long   nowMS        = System.currentTimeMillis();
long   winTime100NS = (nowMS - winEpocMS) * 10000;

Is there a easy/elegant way to pack this data correctly? Are there any Java libs prebuilt to handle reading/writing these rather odd time values?

Bonus poin开发者_高级运维ts to anyone that can explain why we need a 64bit timestamp at the 100NS resolution.

Ok here's the breakdown...

/* time since Jan 1st 1601 00:00:00 UTC */
final long WIN_EPOC_MS = 11644473600000L;
final long now_ms      = System.currentTimeMillis();
final long now_win_ns  = (now_ms + WIN_EPOC_MS) * 10000L;

The reverse should be obvious from the above code. If you want to double check the convertions use w32tm. For example, the following shows that we have the right convertion time to the Unix epoc (note that I am in CST)

w32tm /ntte 116444736000000000
134774 00:00:00.0000000 - 12/31/1969 06:00:00 PM (local time)

Finally, when working with AD make sure the field accepts any value. Some fields take "-1" to mean "now" and "0" may have special meaning. Also, in some cases it seems to matter if the time attribute modification is bundled with other attribute modifications (such as pwdLastSet and unicodePwd).

One last note, I would avoid GregorianCalendar unless you know you have your timezones right (it's easy to mess up).

I not know any Java library that handle the time with that Microsoft-specific format (100 nanosecond intervals since 1601). I think this ways is correct.
You can define winEpocMS as a constant and use:

long winTime100NS = (System.currentTimeMillis() - winEpocMS) * 10000L;

Why we need 64bit timestamp is simple. With 32bit you got 2^32 values (roughly 4,000,000,000), enough to handle seconds since 1970 until 2038 (know as the 2000-year effect on Unix). If you need microseconds or 100 nanoseconds precision, you use bigger values that have to be managed as 64 bit numbers. Java uses milliseconds since 1970 to represent dates and requires long type that is a signed 64 bit number.