3

What I get so far is that w32tm /ntpte uses 2^32 slices starting from 1900/1/1 and ending at 2036/7/2 . And according to my calculations each period is approximately 1 second.The bad thing is that the periods are not consecutevly enumerated and everything is all about periods based on powers over 2. It uses NTP protocol (which documentation is not a not pleasant reading ) and I suppose to get an era and current timestamp and use 2^32 to calculate the desired date -but I have no idea how to get the current time stamp and what era to use . This guy here had some enlightenment , but I cant get the same results as in his examples.

Here's also a simple example:

c:\> w32tm /ntpte 256
0x014F37D494604000 - 109207 18:12:16.0000000 - 1.1.1900  20:12

I have no idea what are these hexes and the second number too , but will be interesting to know.Probably it will be not possible to calculate what I need with simple batch , so if there (in the whole universe) is someone who know how how this is implemented could use a script/ programming language for a illustrative example/explanation .

npocmaka
  • 55,367
  • 18
  • 148
  • 187

1 Answers1

5

I did not manage to figure out what the hex number mean, but the second number is ANSI date, that is the number of days elapsed since 1st January 1601. The parameter is the number of seconds elapsed since 1900-01-01 00:00:00, but it has reverse byte order, the first byte is the least significant (1900-01-01 00:00:01 is encoded as 0x01000000). To have w32tm print out 15th January 2013 22:00 UTC, use this command:

w32tm /ntpte 0xe04fa0d4

or

w32tm /ntpte 3763314900

(conversion from hex to decimal is as if the byte order was normal).

EDIT: It seems that the hex value printed by w32tm is a 64-bit integer representing the number of 100-nanosecond intervals since 1st January 1601. From this article I know this is how Windows stores FILETIME.

EDIT2: After some more playing I found two another things:

  1. Parameter passed to w32tm /ntpte is really a 64-bit integer. As I wrote before, most significant 32-bits represent the number of seconds since 1900-01-01 00:00:00, while least significant 32-bits represent the fraction of second. The whole 64-bit number represents the number of 1/(2 to the power 32) second intervals since 1st January 1900. So 0x0000008000000000 is equal to 1/2 second after 1900-01-01 00:00:00.

  2. The hex value printed by w32tm /ntpte can be directly passed as a parameter to w32tm /ntte

Community
  • 1
  • 1
MBu
  • 2,880
  • 2
  • 19
  • 25
  • hey.Thanks a lot.I'll play with this to check it before mark this as answer ,but look it works :-) – npocmaka Jan 15 '13 at 22:49
  • this makes the connection between w32tm /ntte and w32tm /ntpte more clear - thanks again. – npocmaka Jan 16 '13 at 19:38
  • Your last edit gave more things to think about :-).This command : `w32tm /stripchart /computer:localhost /period:1 /samples:1 /packetinfo` also provides 4 time stamps in 64 bit hex numbers (according to their names and NTP documents) but on a first sight doesn't look in same format as `w32tm /ntpte`. Now I'm trying to see how they are connected. – npocmaka Jan 16 '13 at 21:34
  • 1
    You can pass these timestamps to `w32tm /ntpte` after reversing their byte order. For example I'm getting timestamp `0xD4A22E24AD31C8CF`. To get `w32tm /ntpte` to display date correctly I have to pass `0xcfc831ad242ea2d4` – MBu Jan 17 '13 at 08:05
  • 1
    No I am not :-) I just noticed that the timestamps begin with `D4` while the value in my answer ends with `D4`. The next 6 bits are also the same (compare `A0` with `A2`). And we already figured out that the byte order of `w32tm /ntpte` parameter is reverse. All this gave me a clue to try reversing the timestamp. And bingo! – MBu Jan 17 '13 at 09:18