"the statement in Sybase documentation to the effect that datetime can hold values accurate to 1/300 second is misleading and imprecise" How is it misleading and imprecise? Does it not hold time with accuracy of 1/300 of a second?

What does the query and the result (237) prove exactly?

If my assumptions (and Sybase's documentation) is correct and that it can truly hold accuracy of 1/300, so 300 different values of fractional seconds, then with a random draw of 1000 values, we should expect 300* (1-(1-1/300)^1000) = 289 different values. You got 237 which shows that your data may not be evenly distributed. Try again with 10000 values. The result should be very close to 300.

@ypercubeᵀᴹ. 1/300 of a second is not the same as 3ms. It is also very different from increments (sic) of .000, .003 or .007 seconds (whatever Microsoft means with increment of 0.000 seconds).

I never said anything about 3ms. The 3ms is imprecise. It is about 3.333 ms but that is not precise either. The "Rounded to increments of .000, .003, or .007 seconds" is clumsy writing, I agree. I'm not a MSDN editor or proof-reader to defend them and that's not the only place their writing is clumsy or confusing ;)

@MaxVernon Seconds elapsed since the Epoch denote a point in time. What is a use case where using datetime instead of seconds since the epoch would have made any difference with regard to leap seconds? In most cases I am aware of, client code (that supplies the values to the RDBMS) that computes a timestamp as "seconds since the epoch" uses a library that takes leap seconds into account.

@MarcusJuniusBrutus the simple answer is that they didn't need microsecond or nanosecond accuracy in the 90s when they implemented this - and (quite plausible) they stopped at the highest accuracy the hardware (CPUs, clocks, buses, etc) of that time could offer. The discussion about epoch is mute and irrelevant. I don't see how storing nanoseconds from epoch is much different than storing nanoseconds since midnight.

@ypercubeᵀᴹ Even so, I initially understood "accurate to 1/300 second" to mean that it can precisely hold a time-component of "midnight plus 1/300 of a second" or "37/300 of a second past the hour" or "14:17:35 and 2/300 of a second" --- which is not the case.

So they made a decision: lets store days from 1900-01-01 and ticks from midnight (and what's the smallest tick we can have? 1/300 of a second). OK, done. Due to backwards compatibility, we got this for the next 20 years and many more to come.

No, you still do not understand. That is the case. The format of datetime stores ticks from midnight. 1 tick = 1/300 of a second. The output is what is confusing perhaps, as it doesn't show .xx333333 and .xx66666 but rounds (the output) to .xx3 and .xx6

Thanks, you were right all along but I had to see it myself. Still, Datetime feels very hairy. I was apparently editing the answer at the same time so maybe your edits were lost due to a concurrent editing condition.

Yes, I think they are gone - due to the same time editing.

I can put them back if you like. Or you can edit.

@MarcusJuniusBrutus If you really care about accuracy at that level - whether it stores .003 or .002 or .000 - then yes, it's not exactly clear what it is doing.

I still claim that they do store with accuracy of 1/300 of a second.

@MarcusJuniusBrutus - just a note on your updated answer, which I've also upvoted, converting to format 139 only shows 3 digits since the source data type is a datetime.

But I have no idea - when one provides a .002 values for example - if they store .00 or .00+(1/300).