Working with MS Integer8 / LargeInteger in Java?

Question

I work with AD through LDAP (using Spring LDAP), and I ran into an odd problem while working with Integer8 / LargeInteger, which are used as timestamps outlined here . Namely, my attempts to write in fields of this type led to ...

Invalid field name value here 'attribute value

I tried to put Longs and Strings in the hope that the base implementation would do any necessary transformations, but no luck. This is how I do 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 simple / elegant way to properly package this data? Are there any Java libraries pre-created to handle reading / writing these rather odd time values?

The bonus points to everyone who can explain why we need a 64-bit timestamp at 100NS resolution.

Answer 1

Well here is a 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 converse should be apparent from the code above. If you want to double check conversions, use w32tm. For example, the following shows that we have the correct conversion time in the Unix era (note that I am in CST)

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

, AD , . "-1" "", "0" . , , , , ( pwdLastSet unicodePwd).

, GregorianCalendar, , ( ).

Answer 2

Java, Microsoft (100 1601 ). , . winEpocMS :

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

64- . 32bit 2 ^ 32 ( 4 000 000 000), , 1970 2038 ( 2000- Unix). 100 , , 64- . Java 1970 long, 64- .