Re: DateTime::Set::ICal
> I assume that this only works for things created by > ICal... Right now it works for: - any _bounded_ set, spanset, span, datetime - any unbounded DT:E:ICal set - union()s of those objects - union()s followed by complement()s Other unbounded set operations are not representable with ICal, but I'll keep an eye on it. > Or can I make a set using DT::E::Recurrence and > expect to be able to serialize it out using > DT::F::ICal? All bounded sets are already supported. Unbounded DT:E:Recurrence sets will be, soon. - Flavio S. Glock
Re: DateTime::Set::ICal
I assume that this only works for things created by ICal... Or can I make a set using DT::E::Recurrence and expect to be able to serialize it out using DT::F::ICal? Cool stuff though. -ben On Fri, Jul 04, 2003 at 02:00:34AM +, [EMAIL PROTECTED] wrote: > Ok, I've got DateTime::Set::ICal implemented under > DT:E:Recurrence. It's an 'internal use' class for > recurrences that can be represented using ICal > statements. > > DT::Format::ICal can now format pretty complex sets > as ICal statements: > > example from t/04recurrence.t: > .. > my $exclude = $union2->union( > $ical->parse_datetime( '19980303T030303' ) >)->complement( > $ical->parse_datetime( '19980404T040404' ) >); > @str = $ical->format_recurrence( $exclude ); > > # output: > > RRULE:FREQ=YEARLY;BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA > RRULE:FREQ=YEARLY;BYMONTH=2;BYDAY=SU,MO,TU,WE,TH,FR,SA > RDATE:19980303T030303 > EXDATE:19980404T040404 > > format_recurrence() dies if it can't find a proper > ICal representation for a set. > > - Flavio S. Glock >
Re: DateTime::Format::ISO8601 namepsace
On Thu, Jul 03, 2003 at 12:01:33PM -1000, Joshua Hoblitt wrote: > > We could use a DT::Duration::Set module for things > > like "once a week for 3 weeks" > > That would be ideal. Especially if (given a start or end date) you can turn it into a DateTime::SpanSet > > How is that different from an ICal recurrence? I am not sure. I really haven't looked at the ICal stuff. > > Do we need a DT::Event::ISO8601 ? > > I've been thinking about this for a few days. I don't think that DT::Event::ISO8601 > would be useful on it's own. DT::F::ISO8601 should just return a recurrence. I agree (assuming you mean a DT::SpanSet). The ISO8601 format is so simple that I doubt you would want to create Sets that way (DT::E::Recurrence is much more useful). By the way, I have no idea why the recurrence syntax is at all useful since there is no way to inducate spacing between the items. I suppose if the applications wanted they could ignore the length of the recurrence and treat the starts as point events (or associate lengths with them some other way). But it is in the spec so... -ben
DateTime::Set::ICal
Ok, I've got DateTime::Set::ICal implemented under DT:E:Recurrence. It's an 'internal use' class for recurrences that can be represented using ICal statements. DT::Format::ICal can now format pretty complex sets as ICal statements: example from t/04recurrence.t: .. my $exclude = $union2->union( $ical->parse_datetime( '19980303T030303' ) )->complement( $ical->parse_datetime( '19980404T040404' ) ); @str = $ical->format_recurrence( $exclude ); # output: RRULE:FREQ=YEARLY;BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA RRULE:FREQ=YEARLY;BYMONTH=2;BYDAY=SU,MO,TU,WE,TH,FR,SA RDATE:19980303T030303 EXDATE:19980404T040404 format_recurrence() dies if it can't find a proper ICal representation for a set. - Flavio S. Glock
Re: DateTime::Format::ISO8601 namepsace
> We could use a DT::Duration::Set module for things > like "once a week for 3 weeks" That would be ideal. > How is that different from an ICal recurrence? > Do we need a DT::Event::ISO8601 ? I've been thinking about this for a few days. I don't think that DT::Event::ISO8601 would be useful on it's own. DT::F::ISO8601 should just return a recurrence. -J --
Re: DateTime::Format::ISO8601 namepsace
Ben Bennett wrote: > Remaining future development: > - Add recurrence parsing (only issue is how to handle recurrences of > the form "once a week for 3 weeks" that has no date specified) We could use a DT::Duration::Set module for things like "once a week for 3 weeks" > - Add formatting of objects into ISO8601 strings (hopefully I can > use the recurrence stuff Flavio has been working on to write out a > recurrence). How is that different from an ICal recurrence? Do we need a DT::Event::ISO8601 ? - Flavio S. Glock
Re: DateTime::Format::ISO8601 namepsace
Sorry to reply to myself, but the new version of this thing is available at: http://www.limey.net/~fiji/perl/DateTime-Format-ISO8601-0.01.tar.gz I think this is in roughly releaseable form. I still have some TODO items in the code (actually marked with XXX) but they are small items that clean things up. The POD is rough but reasonable. The test suite is decent (it is all of the strings from the ISO appendix and a few others I threw in). I hope to add more, as well as adding negative tests (i.e. strings I don't expect to be able to parse, or ones that don't match the given type and class). Remaining future development: - Add recurrence parsing (only issue is how to handle recurrences of the form "once a week for 3 weeks" that has no date specified) - Add formatting of objects into ISO8601 strings (hopefully I can use the recurrence stuff Flavio has been working on to write out a recurrence). Please advise. -ben
Re: DateTime::Format::ISO8601 namepsace
Ok, the new interface on mine is complete. The only thing missing is POD and I will do that now. The major problem with merging mine and Joshua's is that they take totally different tacks for the implementation. -ben On Thu, Jul 03, 2003 at 08:56:39AM -1000, Joshua Hoblitt wrote: > > Joshua, why don't you check yours into CVS as DT::F::ISO8601, release it, > > and then you and Ben can merge in all the extra functionality from Ben's > > module. > > I wanted to dump it into CVS long ago but the namespace issue never cleared up. > > I'll try to get my laptop online tonight to make a CPAN release. As I'm on the road > and without regular net access on my laptop I might wait a little bit before asking > SF to insert my tree, so I can keep working (this particular CVS limitation really > drives me nuts). > > > My only "rule" for this is that there should only be one DT::F::ISO8601 > > module, and that _eventually_, it should handle the complete spec. > > Not a problem. > > -J > > --
Re: [Perl-date-time-dev] ICal formatting hints are now stored in Set::Infinite object
Dave Rolsky wrote:
>
> On Thu, 3 Jul 2003, Flavio S. Glock wrote:
>
> > On Thu, 3 Jul 2003, Flavio Soibelmann Glock wrote:
> > > $base_set->{set}{as_ical} = [ uc('recur:'.$recur_str) ];
> >
> > Dave Rolsky wrote:
> > > use a subclass of DateTime::Set.
> >
> > Ok, I think it might work. How about the module name?
> >
> > > Is this ok?
> > > DateTime::Set::ICal
>
> DT::S::ICal is fine, but just inline it in the DT::E::ICal module. No
> need for a separate file, I don't think.
Ok. I will inline it in DT:E:Recurrence,
because it will be used there, too.
- Flavio S. Glock
Re: [Perl-date-time-dev] ICal formatting hints are now stored in Set::Infinite object
On Thu, 3 Jul 2003, Flavio S. Glock wrote:
> On Thu, 3 Jul 2003, Flavio Soibelmann Glock wrote:
> > $base_set->{set}{as_ical} = [ uc('recur:'.$recur_str) ];
>
> Dave Rolsky wrote:
> > use a subclass of DateTime::Set.
>
> Ok, I think it might work. How about the module name?
>
> > Is this ok?
> > DateTime::Set::ICal
DT::S::ICal is fine, but just inline it in the DT::E::ICal module. No
need for a separate file, I don't think.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: [Perl-date-time-dev] ICal formatting hints are now stored in Set::Infinite object
On Thu, 3 Jul 2003, Flavio Soibelmann Glock wrote:
> $base_set->{set}{as_ical} = [ uc('recur:'.$recur_str) ];
Dave Rolsky wrote:
> use a subclass of DateTime::Set.
Ok, I think it might work. How about the module name?
> Is this ok?
> DateTime::Set::ICal
- Flavio S. Glock
Re: DateTime::Format::ISO8601 namepsace
> Joshua, why don't you check yours into CVS as DT::F::ISO8601, release it, > and then you and Ben can merge in all the extra functionality from Ben's > module. I wanted to dump it into CVS long ago but the namespace issue never cleared up. I'll try to get my laptop online tonight to make a CPAN release. As I'm on the road and without regular net access on my laptop I might wait a little bit before asking SF to insert my tree, so I can keep working (this particular CVS limitation really drives me nuts). > My only "rule" for this is that there should only be one DT::F::ISO8601 > module, and that _eventually_, it should handle the complete spec. Not a problem. -J --
Re: DateTime::Format::ISO8601 namepsace
On Thu, 3 Jul 2003, Joshua Hoblitt wrote: > > Well mine currently does that and parses durations... > > I already said I'd be happy to use your module for parsing durations if > you beat me to it. > > I set the bar low enough to get something stable for release. Joshua, why don't you check yours into CVS as DT::F::ISO8601, release it, and then you and Ben can merge in all the extra functionality from Ben's module. Or, if you don't like this, do something else ;) My only "rule" for this is that there should only be one DT::F::ISO8601 module, and that _eventually_, it should handle the complete spec. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Format::ISO8601 namepsace
> Well mine currently does that and parses durations... I already said I'd be happy to use your module for parsing durations if you beat me to it. I set the bar low enough to get something stable for release. -J --
Re: DateTime::Format::ISO8601 interface questions...
> Probably for unambiguous cases we should just allow: > > $iso->parse_datetime($string) I did that. > For more complex cases we can do: > > $iso->parse_datetime( datetime => $string, >... # extra params > ) I went with $iso->parse_time as the 6 ambiguous strings are either dates or times. The default is to parse them as dates (what ->parse_datetime does), if you really want them to be times you can use this method. > This probably works better than many methods, in this case, because there > seem to be many combinations of different parameters (format, base object, > timezone, etc.) so trying to method-ize those would generate a ridiculous > number of methods. Yep. It seemed easier to build a regex for each format. -J --
Re: DateTime::Format::ISO8601 interface questions...
Cool, that is the method that I have started on. -ben On Thu, Jul 03, 2003 at 01:03:09PM -0500, Dave Rolsky wrote: > On Thu, 3 Jul 2003, Ben Bennett wrote: > > > There is a lot to work out, but once the interface is clear it should > > be very quick to implement. > > > > Do you have any suggestions for what the interface should be or should > > I just take a whack at it and see what people think? > > Probably for unambiguous cases we should just allow: > > $iso->parse_datetime($string) > > For more complex cases we can do: > > $iso->parse_datetime( datetime => $string, >... # extra params > ) > > This probably works better than many methods, in this case, because there > seem to be many combinations of different parameters (format, base object, > timezone, etc.) so trying to method-ize those would generate a ridiculous > number of methods. > > > -dave > > /*=== > House Absolute Consulting > www.houseabsolute.com > ===*/
Re: DateTime::Format::ISO8601 interface questions...
On Thu, 3 Jul 2003, Ben Bennett wrote: > There is a lot to work out, but once the interface is clear it should > be very quick to implement. > > Do you have any suggestions for what the interface should be or should > I just take a whack at it and see what people think? Probably for unambiguous cases we should just allow: $iso->parse_datetime($string) For more complex cases we can do: $iso->parse_datetime( datetime => $string, ... # extra params ) This probably works better than many methods, in this case, because there seem to be many combinations of different parameters (format, base object, timezone, etc.) so trying to method-ize those would generate a ridiculous number of methods. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Format::ISO8601 interface questions...
There is a lot to work out, but once the interface is clear it should
be very quick to implement.
Do you have any suggestions for what the interface should be or should
I just take a whack at it and see what people think?
-ben
On Thu, Jul 03, 2003 at 11:43:03AM -0500, Dave Rolsky wrote:
> On Thu, 3 Jul 2003, Ben Bennett wrote:
>
> >
> > I am not sure what interface to use for the advanced features of the
> > ISO8601 parser I wrote. Right now I use a quick hack to make it work
> > so I can test the parser. It should be easy for me to change the
> > interface to something sane, I just don't know what that should be.
> >
> > The basic usage should be:
> > --
> > my $iso = DateTime::Format::ISO8601
> > my $dt = $iso->parse_datetime("20030211");
> > --
> >
> > However, I want to be able to accept the following optional arguments:
> > - The classes of formats to parse (Dates, Times, DateTimes,
> >Durations, Recurrences)
> > - The base DateTime object to use when things are implied (e.g. the
> >date component when dealing with times, or any Truncated format,
> >and some recurrences) If not supplied this defaults to now().
> > - The types to allow (each group is independent so you can have a
> >Basic, Reduded, Week, Fractional, Expanded DateTime format):
> >
> >- Basic (no separators)
> >- Extended (with separators)
> >
> >- Complete (fully specified class, no pieces missing)
> >- Reduced precision (missing lower order items, e.g. year only)
> >
> >- Truncated (whether higher order items are implied, e.g. ---12
> > specifies 12th day of current month and year)
> >
> >- Fractional (Time components may be represented as a fraction)
> >
> >- Expanded (The year may have additional digits and may be negative)
> >
> >- Ordinal (Days are expressed as Nth day of a year)
> >- Week (Days are expressed as Nth day of Mth ISO week)
> >
> >- Timezone (Whether a timezone is allowed)
>
> Ok, so basically there's a lot left to work out for your parser.
>
> In that case, I think the ideal thing to do would be to release Joshua's
> parser now as DT::F::ISO8601, and then to continue work on yours, making
> it backwards compatible with Joshua's.
>
> Or in other words, please merge the damn things! ;)
>
>
> -dave
>
> /*===
> House Absolute Consulting
> www.houseabsolute.com
> ===*/
Re: DateTime-Fiscal-Year 0.01
On Thu, 3 Jul 2003, Jesse Shy wrote: > I think I got everything up that is needed. I want to change the API a bit, to be more like the other DT modules. Right now it's not even close to the other modules. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Format::ISO8601 interface questions...
On Thu, 3 Jul 2003, Ben Bennett wrote:
>
> I am not sure what interface to use for the advanced features of the
> ISO8601 parser I wrote. Right now I use a quick hack to make it work
> so I can test the parser. It should be easy for me to change the
> interface to something sane, I just don't know what that should be.
>
> The basic usage should be:
> --
> my $iso = DateTime::Format::ISO8601
> my $dt = $iso->parse_datetime("20030211");
> --
>
> However, I want to be able to accept the following optional arguments:
> - The classes of formats to parse (Dates, Times, DateTimes,
>Durations, Recurrences)
> - The base DateTime object to use when things are implied (e.g. the
>date component when dealing with times, or any Truncated format,
>and some recurrences) If not supplied this defaults to now().
> - The types to allow (each group is independent so you can have a
>Basic, Reduded, Week, Fractional, Expanded DateTime format):
>
>- Basic (no separators)
>- Extended (with separators)
>
>- Complete (fully specified class, no pieces missing)
>- Reduced precision (missing lower order items, e.g. year only)
>
>- Truncated (whether higher order items are implied, e.g. ---12
> specifies 12th day of current month and year)
>
>- Fractional (Time components may be represented as a fraction)
>
>- Expanded (The year may have additional digits and may be negative)
>
>- Ordinal (Days are expressed as Nth day of a year)
>- Week (Days are expressed as Nth day of Mth ISO week)
>
>- Timezone (Whether a timezone is allowed)
Ok, so basically there's a lot left to work out for your parser.
In that case, I think the ideal thing to do would be to release Joshua's
parser now as DT::F::ISO8601, and then to continue work on yours, making
it backwards compatible with Joshua's.
Or in other words, please merge the damn things! ;)
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: [Perl-date-time-dev] ICal formatting hints are now stored in Set::Infinite object
Dave Rolsky wrote:
>
> On Thu, 3 Jul 2003, Flavio Soibelmann Glock wrote:
> > +# note: the {as_ical} key is a DT::Event::ICal extension
> > +# to Set::Infinite
> > +$base_set->{set}{as_ical} = [ uc('recur:'.$recur_str) ];
>
> Please don't do this. Just use a subclass of DateTime::Set.
Is this ok?
DateTime::Set::ICal
I'm not happy with this solution.
There should exist another way to add this kind of
properties to an object.
If we could find an elegant way to fix this,
it would be applicable to a bunch of other problems.
In this particular case, we could use something like:
$dt_set->set_formatter( \&my_sub );
such that I'd write:
$base_set->set_formatter(
sub { uc('recur:'.$recur_str) }
);
and read it back with
print $base_set->as_string;
Yet another API option, much more flexible:
$base_set->set_formatter(
ical => sub { uc('recur:'.$recur_str) }
);
and then use it with
print $base_set->as_string( 'ical' );
- Flavio S. Glock
DateTime::Format::ISO8601 interface questions...
I am not sure what interface to use for the advanced features of the
ISO8601 parser I wrote. Right now I use a quick hack to make it work
so I can test the parser. It should be easy for me to change the
interface to something sane, I just don't know what that should be.
The basic usage should be:
--
my $iso = DateTime::Format::ISO8601
my $dt = $iso->parse_datetime("20030211");
--
However, I want to be able to accept the following optional arguments:
- The classes of formats to parse (Dates, Times, DateTimes,
Durations, Recurrences)
- The base DateTime object to use when things are implied (e.g. the
date component when dealing with times, or any Truncated format,
and some recurrences) If not supplied this defaults to now().
- The types to allow (each group is independent so you can have a
Basic, Reduded, Week, Fractional, Expanded DateTime format):
- Basic (no separators)
- Extended (with separators)
- Complete (fully specified class, no pieces missing)
- Reduced precision (missing lower order items, e.g. year only)
- Truncated (whether higher order items are implied, e.g. ---12
specifies 12th day of current month and year)
- Fractional (Time components may be represented as a fraction)
- Expanded (The year may have additional digits and may be negative)
- Ordinal (Days are expressed as Nth day of a year)
- Week (Days are expressed as Nth day of Mth ISO week)
- Timezone (Whether a timezone is allowed)
I would also like to be able to return additional information about
the format and the parsed components. This would allow some
introspection when dealing with an unknown format. For instance if I
know I may get a reduced format I may want to handle it differently in
my application, but I need to know if I am dealing with a year, decade
or century.
I could handle this by detecting how many items are passed as
arguments to parse_datetime() and handling it as a hash if I get more
than 1. Similarly I can return different items if I am called in
array context... However, if you call parse_datetime() and get a
DateTime::Duration object back that seems wrong.
I think the thing to do is make the parse_datetime() be a wrapper for
a sub with named parameters that restricts things to DateTime objects
only. If you want the full power of the parser you need to call
parse_iso8601() or something. Only parse_is08601 will support
returning multiple items using wantarray to detect the calling
context.
Or I perhaps you have to make an object and call parse_datetime()
through the object if you want to do anything complex.
I am leaving the formatting side out of the intial discussion, but it
has similar problems, for instance it needs to be able to take similar
format parameters to work out what kind of string to produce.
Does anyone have any suggestions. I looked at the existing DT::F::
modules but they don't appear to have any similar interface problems.
Any suggestions would be appreciated.
Thanks,
-ben
DateTime-Fiscal-Year 0.01
I think I got everything up that is needed.
Re: DateTime::Format::ISO8601 namepsace
On Thu, 3 Jul 2003, Ben Bennett wrote: > Well mine currently does that and parses durations... > > Joshuas can probably be changed to do so, but I am not motivated to > do the work. So, no offense to Joshua, I think yours should be the one with the DT::F::ISO8601 namespace. I don't see the need for two _highly_ overlapping modules. It'll just confuse end users. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Format::ISO8601 namepsace
Well mine currently does that and parses durations... Joshuas can probably be changed to do so, but I am not motivated to do the work. -ben On Thu, Jul 03, 2003 at 10:13:04AM -0500, Dave Rolsky wrote: > On Thu, 3 Jul 2003, Ben Bennett wrote: > > > I am okay with this decision. However Joshua's parser does not allow > > selection of which pieces of the spec are applicable so you can have > > ambiguous cases. > > > > Anyway, I will rename my parser to > > DateTime::Format::ISO8601::Complete and release it. > > Ugh, no. Please, let's just have one parser. Can't we have one that, by > default, parses all the common, unambiguous cases, and also allows you to > specify additional info so that ambiguous formats are parsed as well? > > > -dave > > /*=== > House Absolute Consulting > www.houseabsolute.com > ===*/
Re: DateTime::Format::ISO8601 namepsace
On Thu, 3 Jul 2003, Ben Bennett wrote: > I am okay with this decision. However Joshua's parser does not allow > selection of which pieces of the spec are applicable so you can have > ambiguous cases. > > Anyway, I will rename my parser to > DateTime::Format::ISO8601::Complete and release it. Ugh, no. Please, let's just have one parser. Can't we have one that, by default, parses all the common, unambiguous cases, and also allows you to specify additional info so that ambiguous formats are parsed as well? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Format::ISO8601 namepsace
I am okay with this decision. However Joshua's parser does not allow selection of which pieces of the spec are applicable so you can have ambiguous cases. Anyway, I will rename my parser to DateTime::Format::ISO8601::Complete and release it. -ben On Thu, Jul 03, 2003 at 06:39:58PM +1000, Iain Truskett wrote: > * Joshua Hoblitt [03 Jul 2003 18:09]: > > I've resolved the last known bug my ISO8601 parser and I > > believe it is ready for CPAN. Unless I hear an objection > > I'm going to use the DateTime::Format::ISO8601 namespace. > > +1 > > Please do. > > > I'm not claiming that this is the right namespace to use > > but the indecision needs to be settled. If this turns out > > to be the wrong choice things can always be renamed later. > > Do you parse ISO8601 dates? If so, you're there. > Any differences can be later integrated =) > > > cheers, > -- > Iain.
Re: [Pdx-pm] Re: [PLUG] Re: Slides from YAPC presentation
(Cross-replying to three lists, sorry for cross-over) On Tuesday, Jul 1, 2003, at 11:48 US/Pacific, Joshua Hoblitt wrote: the laser light shows at OMSI According to this weeks Willamette Week, OMSI has a brand new planetarium in place!! WW made a cryptic comment about tons of cool geeky stuff there, I'm sure the projectionists would be pleased as punch to go in to details if they knew that the crowd would be properly appreciative. :-) - Daniel C. Stillwaggon <[EMAIL PROTECTED]>
Re: DateTime::Format::ISO8601 namepsace
* Joshua Hoblitt [03 Jul 2003 18:09]: > I've resolved the last known bug my ISO8601 parser and I > believe it is ready for CPAN. Unless I hear an objection > I'm going to use the DateTime::Format::ISO8601 namespace. +1 Please do. > I'm not claiming that this is the right namespace to use > but the indecision needs to be settled. If this turns out > to be the wrong choice things can always be renamed later. Do you parse ISO8601 dates? If so, you're there. Any differences can be later integrated =) cheers, -- Iain.
DateTime::Format::ISO8601 namepsace
I've resolved the last known bug my ISO8601 parser and I believe it is ready for CPAN. Unless I hear an objection I'm going to use the DateTime::Format::ISO8601 namespace. I'm not claiming that this is the right namespace to use but the indecision needs to be settled. If this turns out to be the wrong choice things can always be renamed later. -J --
