Time problems present themselves as primarily about the rotation of the planet about its axis, or about the apparent position of the sun and other stars in the sky. But time problems are also about different positions on the surface of the earth and different positions of the earth about the sun. Not just time, but also space.
(Definitely need to go to sleep 'cos this is way too complicated.) After writing all the stuff below, and then thinking about it after dinner, I think date ranges really need to be treated like line segments, and possibly like a small web of segments. The start point and end point are each multi-dimensional. Any point in time is a reference to some origin time, for example, seconds from the unix epoch. But then local times are measured from two points, the epoch and UTC. And these are still individual points in time. Time spans now include the relationships to the epoch, to UTC and then to each other. Then you may have both Alice and Bob planning events from different time zones where each participant views the "same" time range from different positions on the Earth. And complicated more when Eve also listens in.
I was originally thinking of adding many rows to the 'radarData' representing the same date in various units counted from the Epoch: milliseconds, seconds, minutes, hours, days, weeks, months, quarters, years.
Another thought was to render dates just as milliseconds but somehow introduce many unit conversions into the page for each of those resolutions.
The general goal was to allow the consumer of those dates to operate at whatever resolution was appropriate for their particular problem.
I ended up preferring just one example, days, but hoped it might provoke conversation about how to represent dates.
Now... date ranges are another animal. And actually, for the Allowance experiment with Calendar and Method plugins what I really needed was a date range from a given date to today, but then rounded to weeks, and truncated to the nearest previous Sunday.
Because, then I can have the code recompute that date range every time you look at the page and then convert the weeks to dollars using the kid's allowance. With that trick, I never have to enter a deposit transaction into their ledger. The balance just automatically expands with time.
I only have to actually track their purchases.
I believe the rounding of date ranges into hours and weeks is useful for almost any contractual computation. Hourly workers are paid an hourly rate. Salaried workers are paid a bi-weekly rate, and usually starting and ending on Fridays.
That said, date ranges are not only used for computing finances. Many times date ranges are really spans of space-time, not just time alone. For example, virtual meetings where participants are in different time zones. Or when events for a trip are arranged and scheduled in one time zone but will occur in a different time zone. And ironic that we call these "time zones" when they're really about differences in space.