On Sat, 6 Jul 2003, Rick Measham wrote: > 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.
It wasn't that it didn't go down well, I just couldn't understand what it was for. This was largely because the docs compared it to DT::Duration, but were wrong in several cases about what they said re: DT::Dur, so I couldn't tell if it solved an actual problem! > 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? But of course, you do _know_ (in theory ;) that it's July 6th. And if someone tells me something will occur in 60 seconds, the fact that I _don't_ know the date doesn't change the fact that those 60 seconds might include a leap second ;) > 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. I guess my assumption is that the end user _must_ know what date a time is associated with, even if they don't save that in the DB. Anyway, what I'd _really_ like to see is some actual application code that uses your proposed module. I'm really not violently against it, I just want to see how you would use it in an app. People keep proposing interesting ideas, but unless they also say "here's X different real-world application uses", I'm going to keep vetoing them ;) It's great that there's so much interest in the DateTime project, but that means my most important role has changed from "person who implements core stuff" to "person who tells everybody 'No' so project doesn't explode into a ridiculously complex, unusable mess". I take this role seriously, and I'm very leary of adding new core objects/classes without very good reason. Every new core object requires lots of docs, more FAQ entries, and more explanation on this list, not to mention more slides in my presentations ;) Note, I'm not saying you don't have them, I'm just saying that _I_ don't understand them (yet?). -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/
