Hex is not a strong point. 701265 is 51 B3 0A 00? Is that in little-endian order?
Then don't use it. "\d701265" will encode that number in a dword, exactly as you want, with no hassles about endianness. (But don't use that either.) If you want to know how it came out on the other end, just encode and decode, and read the decoded sprite. (And, yes, it is LE.)
The proper way to encode January 1, 1920, for the long-date properties, is one of "\d1/1/1920", "\d1-1-1920", "\d1920/1/1", or "\d1920-1-1". This is either YMD or DMY order. No middle-endian silliness is supported, even if I do live in a country that chooses to use that format.
 I wrote this part of the spec, hence why my preferences have bearing here.
To get a good answer, ask a Smart Question
. Similarly, if you want a bug fixed, write a Useful Bug Report
. No TTDPatch crashlog? Then follow directions
) | PlaneSet
) | grfcodec
) | grfdebug.log parser