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
