I don't know the full internal details or the motivation behind the choice, but datetime
is stored internally as - essentially - two 4-byte integers. One represents date, the other represents time. I suspect you lose some precision in the latter because of the way ticks / milliseconds have been handled since the very first versions of SQL Server, but again, I don't know low-level implementation details.
Related questions for more background info:
What is the internal representation of datetime in sql server?
Allow Entity Framework 4.5 to use datetime2 with SQL Server CE4
In order to support the precision you want without moving the value in and out of binary format, I would suggest using LocalDB which has the same portability advantages of Compact but without many of the feature limitations (such as support for the more precise datetime2
type - which I assure you takes 6-8 bytes, not 54 :-)).