On Sun, 2003-07-06 at 09:27, Matt Sisk wrote: > I was terming a 'clock' as anything with periodicity. An 'unbounded' clock would > be a clock without an associated epoch or starting date. > > A clock without context still has characteristics and can be compared to other > clocks (for example, compare interval lengths).
A while back I posted a DateTime::Time module that was basically an unbounded clock. It didn't go down so well. Maybe some of the stuff in the docs wasn't right, but still it was useful. Basically the biggest changes I'd make to it now would be to edit the overloads so that if someone added the object to a bounded datetime it would return a bound datetime. (Maybe it already did .. can't remember) and I'd do the same with set(). Once we got an actual date, the clock would be bound. Currently we have no way of creating a time, or unbounded datetime. I imagined that such a clock would think of minutes as 60 seconds and days as 24 hours. Despite leap-seconds and leap-years. Without a date we have no idea when they occur. The difference between a Duration and a DateTime::Time is that a duration thinks of itself in terms of its contructors. It is an array of days, hours, etc.. A DateTime::Time would probably be a Calendar where all things are normalised. In my implementation it thought of itself as a number of seconds. The other difference was in the API. DateTime::Time uses the same API as DateTime herself. This aids in understanding. I'd even go so far as to suggest that DateTime::Time should be invisible. Create a DateTime without a Date and you get back a DateTime::Time object until such time as you provide enough information to be able to bind it. I can still hear people saying 'But why?'. Well the answer is because people don't think of times as bound by default. When your wife asks you what time it is you look at the clock on the wall. The time there is unbounded. You don't say "It's 9:47 am, but only because it's the 6th of July 2003". Many database implementations (including the SQL92 standard AFAIK) have a time-only column type. What do we do with these? At the moment if I come across something like this I return 0000-Jan-00. But that's silly. They didn't mean that when they set the time. They just didn't tell me when it was. Why not? because they didn't care. Maybe they have a log file for July 6th but from the log there's no way of knowing it's July 6th. All we know is that each entry has a time. We can't DateTime it. However we should be able to. We should still be able to access it using the same calls we use for bound times. We should be able to format it and manipulate it and add to it the same way. </rant> Cheers! Rick
