Re: DateTime-Fiscal-Year 0.01
On Thu, 3 Jul 2003, Jesse Shy wrote: Yes, please, tell me what to change. I dont know what it should have been. I looked at the date time module and the DateTime-TimeZone modules for examples and read the standards from the web site. So I used named parameters, did I miss something that should have been obvious? I am not sensitive, I am here to get better ( and maybe contribute something useful). It's the API that's not right. It doesn't match the existing DateTime.pm API. For example, DateTime.pm does not have any methods starting with get_. Additionally, your get_ methods only work if the non-get version was called first, because they rely on a cached value! This is really bad, because it forces the end user to understand how the caching works. This should just be transparent. Also, I want to add a quarter_of_financial_year method. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Set::ICal
The DT::Set::ICal class is inlined into DT::E::Recurrence. Maybe it should be published separately? I think so - not everyone that uses DT::E::Recurrence will want it. -J --
Re: DateTime::Format::ISO8601 namepsace
So is there any conclusion here? Should I commit my module or will Joshua commit his? -ben
Re: DateTime::Set::ICal
Flavio wrote: The DT::Set::ICal class is inlined into DT::E::Recurrence. Maybe it should be published separately? Joshua Hoblitt wrote: I think so - not everyone that uses DT::E::Recurrence will want it. But if I added support for ICal formatting, then DT::E::Recurrence would _always_ require DT::Set::ICal! Now I'm thinking of keeping DT:E:Recurrence as-is, and only support DT:E:ICal recurrences formatting. People who need ICal output would use DT:E:ICal instead of DT:E:Recurrence. The DT::Set::ICal class would be inlined into DT::E::ICal, as Dave said. - Flavio S. Glock
Re: DateTime::Set::ICal
Dave Rolsky wrote: it doesn't really have much use outside DT::E::Recurrence, does it? It would be useful for specifying ICal statements for user-defined callback recurrences, in case someone needs it. There is an example in the format_recurrence() docs. - Flavio S. Glock
Re: DateTime::Format::ISO8601 namepsace
So is there any conclusion here? Should I commit my module or will Joshua commit his? I thought there was a conclusion... I'm planning on moving my tree to SF CVS as soon as I return from OSCON. Then we can merge as much as we can from your tree into mine. A new version was sent to CPAN last night. A road-map was sent to the list along with the release. Basically the next release will be bug fixes and more tests - hopefully a thousand or more new tests. Then the ISO section 5.5 stuff can be started on. 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). By collaborating with Iain while working on my ISO parser many very useful features have been incorporated into DT::F::Builder. I'd like to continue along this path as it has potential benefits for other authors. Of course your help is welcomed. As I've said from the beginning I think your parser is very interesting and I don't want to see you abandon it. Perhaps it should be extracted from the ISO8601 specific stuff and rolled into a stand alone module for specifying date/time formats. Maybe DateTime::Format::Grammar? Cheers, -J --
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 ===*/
