[MvL]
> A. t1=t2=1385161652120375500
> B. pygettimeofday truncates this to 1385161652.120375
> C. time.time() converts this to float, yielding
>   0x1.4a3f8ed07b439p+30 i.e.
>   (0.6450161580556887, 31)
>   1385161652.120375 (really .1203749566283776)
> D. _PyTime_ObjectToDenominator converts this to
>   1385161652.120374917
> E. time_t_to_FILE_TIME convert this to
>   1385161652.120374900

Got it.  It's not surprising we can't round-trip, but it's annoying we can't always round-trip even if there are no nanoseconds to lose at the start :-(  The only part here that rounds is step C - everything else truncates.

For example, start with 1385161652120374000.  B is exact then, returning seconds 1385161652 and usecs 120374.

C doesn't do _much_ damage, returning

1385161652.120374 == 0x1.4a3f8ed07b435p+30

D. breaks that into
    1385161652.0
and
    0.12037396430969238
yielding seconds 1385161652 and numerator 120373964.  The last part is a little truncated, but the major loss comes in E, which chops off the final "64" - we end up changing

    1385161652120374000 into
    1385161652120373900

There's a reason C's time_t is almost always implemented as an integer type ;-)  I expect we'd be better off if we represented times internally as 64-bit ints, used double for the output of time.time(), and refused to accept doubles for any purpose - LOL ;-)