Re: DT::Duration::Set
Dave Rolsky [EMAIL PROTECTED]: Can you and/or Joshua explain what this would be used for? elbowing in Unbounded clocks? Matt
Re: DT::Duration::Set
Maybe there is something fundamental we can boil out of DT::E::R. hmmm... I found out a way to get a duration-set out of DT::E::R: $dt_set = new DT::E::R( %param ); # datetimes $dur_set = $dt_set - $dt; # durations! It will not work under the current implementation, but it can be done. - Flavio S. Glock
Re: DT::Duration::Set
Can you expand on this please? -ben On Sat, Jul 05, 2003 at 04:31:12AM -0400, Matt Sisk wrote: Dave Rolsky [EMAIL PROTECTED]: Can you and/or Joshua explain what this would be used for? elbowing in Unbounded clocks? Matt
Re: DT::Duration::Set
Can you expand on this please? 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). All the talk about duration sets, plus some earlier talk about time-only datetime objects, sounded like these concepts had a lot in common with clocks. (perhaps I'm just odd) Matt
Re: DT::Duration::Set
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 -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
Re: DT::Duration::Set
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 ===*/
DT::Duration::Set
Joshua Hoblitt wrote:
I'm planning on working with Iain and Flavio for any changes needed
to DT::F::Builder or DT::Duration::Set (when it's written).
Ok, how about this for DT::Duration:Set:
- convert from 'duration' to 'set'
$dt_dur_set = from_durations( durations = [ $dur1, $dur2, $dur3 ] );
# set = ( $dur1, $dur2, $dur3 )
- recurrence:
$dt_dur_hourly = from_recurrence(
next = sub {
my %deltas = $_[0]-deltas;
DateTime::Duration-new(
months = $deltas{months},
days = $deltas{days},
hours = 1 + $deltas{hours}
)
}
);
# set = ( ... -PT2H, -PT1H, PT0, PT1H, PT2H ... )
- set a 'start time', result is a DT::Set
add_datetime( date = $dt )
# DT::Set = ( $dt + $dur1, $dt + $dur2, $dt + $dur3 )
- there are many other possibilities, let me know if you need more:
DT::Dur::Span
DT::Dur::SpanSet
add_datetime_set( $dt_set )
...
Plus all the other common set methods:
empty_set
clone
iterator / as_list
union / intersection / complement
intersects / contains
previous / next / current / closest
- Flavio S. Glock
Re: DT::Duration::Set
On Fri, 4 Jul 2003, Flavio S. Glock wrote: Joshua Hoblitt wrote: I'm planning on working with Iain and Flavio for any changes needed to DT::F::Builder or DT::Duration::Set (when it's written). Ok, how about this for DT::Duration:Set: Can you and/or Joshua explain what this would be used for? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DT::Duration::Set
Dave Rolsky wrote: Can you and/or Joshua explain what this would be used for? It can be used to specify a time-set, in which you know the time-differences but you don't know the absolute start-time in advance. Something like: the store is open 08:00-12:00, 13:00-18:00. You could add this object to a datetime-set of non-holiday days, for example. Of course, this timetable could be a 2-dimensional array of durations. Sets are just another way to do it. - Flavio S. Glock
Re: DT::Duration::Set
Flavio S. Glock wrote: Of course, this timetable could be a 2-dimensional array of durations. Sets are just another way to do it. The 'add_duration' in DateTime::Set could be easily extended into: $dt_set-add_durations( durations = @durations ); This might be a good alternative: we can store duration sets as list-of-durations, and convert to DT::Set when we need it. Of course, this will not allow for duration-recurrences. - Flavio S. Glock
Re: DT::Duration::Set
Of course, this will not allow for duration-recurrences. Aren't recurrences basically a set of durations at fixed intervals? Could duration sets mimic the DT::E::Recurrence API? Then you could iterate from a start time until the end of the set (would have to look for some sort of flag returned from the set). So then is it reasonable to say a recurrence is an infinite duration set and just a special case of duration sets? Maybe there is something fundamental we can boil out of DT::E::R. hmmm... -J --
Re: DT::Duration::Set
That's all correct, and the implementation is cut-and-paste DT::Set/DT::E::Recurrence code. Dave wants to know _why_ we want this! - Flavio S. Glock Of course, this will not allow for duration-recurrences. Aren't recurrences basically a set of durations at fixed intervals? Could duration sets mimic the DT::E::Recurrence API? Then you could iterate from a start time until the end of the set (would have to look for some sort of flag returned from the set). So then is it reasonable to say a recurrence is an infinite duration set and just a special case of duration sets? Maybe there is something fundamental we can boil out of DT::E::R. hmmm...
Re: DT::Duration::Set
On Sat, 2003-07-05 at 06:10, Dave Rolsky wrote: Can you and/or Joshua explain what this would be used for? $greatest_duration = DateTime::Duration::set-new( from_durations = [$d1, $d2, $d3] )-max( from = DateTime-now() ); Also, -min( from = $dt ) -median( from = $dt ) -mean( from = $dt ) # would return a duration object that doesn't necessarily match one of the set. Just some thoughts. Cheers! Rick
Re: DT::Duration::Set
That's all correct, and the implementation is cut-and-paste DT::Set/DT::E::Recurrence code. Well I have it strait in my head now. :) Dave wants to know _why_ we want this! ISO8601 recurring time intervals. -J --
Re: DT::Duration::Set
On Fri, 4 Jul 2003, Joshua Hoblitt wrote: That's all correct, and the implementation is cut-and-paste DT::Set/DT::E::Recurrence code. Well I have it strait in my head now. :) Dave wants to know _why_ we want this! ISO8601 recurring time intervals. And what _are_ these, and what do people use them for? I guess I can't see why this is needed in addition to SpanSet objects. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
