Dave Rolsky wrote:
On Thu, 19 Feb 2009, Darren Duncan wrote:
And which is why subsecond and whole-second *can* be combined. Appropriate separation allows better accuracy in letting people express what they mean rather than shoehorning it into a less accurate space, like DateTime.pm shoehorns into Days+Seconds+Nanoseconds.


Not to get too off-topic, but this is just incorrect. The way DateTime.pm handles this _internally_ is to store days since an epoch, and seconds into the day (and nanoseconds).

That's what I thought I was saying; you use those 3 units.

Ignoring the precision lost by using nanoseconds, this storage format is otherwise perfectly precise. While the number of seconds per minute, hour, or day varies, we can _calculate_ the hour & minute from that value. Similarly, we can _calculate_ the year, month, & day with perfect accuracy.

It's not necessary to store each unit internally in order to get everything right, and not doing so makes some things a lot easier (though it makes other things harder ;)

I prefer to make value representation simpler at the possible cost of calculation, focusing on being able to encode accurately what you know or don't know or mean to say or don't mean to say. Using a representation in terms of an epoch is going more the other way. With my preference, you don't need to do any calculations with lookup tables etc in order to know what you have in human understandable terms; rather you just need that to derive something else relative to where you are.

Well, I can see reasons for both ways, but I prefer the more split apart way, and that's also what SQL and some other data-focused languages and some other languages do, not to mention what people do, which I think is a good precedent.

And of course, my argument is more what the role, aka the interface looks like, where focusing on accuracy is important. The implementation could go all sorts of other ways in order to make storage space or calculations or comparisons more efficient.

-- Darren Duncan

Reply via email to