Почему тип datetime в SQL Server Compact округляет значения?

Я столкнулся с чем-то, что меня удивило.

Я использую WinPcap для сбора данных из сети. Внутри WinPcap использует счетчики производительности Windows для создания временных меток. Я знаю, что они подвержены дрейфу, но эти метки времени, тем не менее, имеют точность до микросекундного уровня.

Если я вставлю эти метки времени в базу данных SQL Server Compact 4.0 как значение datetime и извлеку их позже, то замечу, что точность упала до миллисекунд.

Например,

10:52:19.706084 -> 10:52:19.706000

С тех пор я прочитал здесь что SQL Server округляет значения с типом datetime до 0,000, 0,003 или 0,007 миллисекунды. Это объясняет, что происходит.

Теперь поле datetime использует 8 байтов для хранения своих данных, 4 байта для даты и 4 миллисекунды с полуночи. Но если я вызову DateTime.ToBinary(), я верну 8-байтовое число, представляющее значение со всей его точностью. На самом деле, если я запишу это значение в базу данных в столбце bigint, а затем вызову DateTime.FromBinary() при извлечении этого значения, я получу исходное значение с той же точностью.

Это подход, который я собираюсь использовать, но мне все еще любопытно: почему исходный тип datetime в SQL Server Compact не использовал механизм хранения ToBinary/FromBinary DateTime?

ИЗМЕНИТЬ:

Как справедливо отмечает Аарон Бертран, SQL Compact не поддерживает datetime2. Кроме того, datetime2 использует 6, 7 или 8 байтов, а не 54 байта в обычном SQL Server. Однако мой основной вопрос остается в силе.