Perllib for dates

>It's "Perl". I don't know about faster, but
DateTime is widely 
>considered to be more correct than Date::Manip. Within
the DateTime 
>framework, I believe that DateTime::Set handles
recurring dates.

>   http://search.cpan.org/dist/DateTime-Set/lib/DateTim
e/Set.pm

Ok, I'll check it out to understand the capabilities of
DateTime::Set and whether it cuts the mustard functionally. 
A nice feature of Date::Manip's recurrence capabilities is
that it handles virtually any type of recurring event --
(e.g. the last day of February each year, every Monday and
Friday of the second week of every third month every 3 years
between last January 1 and March 9 years from now).

> BTW, Bricolage uses DateTime for all of its date and
time calculations.

>> 2) Any suggestions for a caching / storage
architecture to store 
>> pre-calculated dates for the event?  Depending on
performance, I 
>> might end up having to calculate all recurrences of
the event at 
>> SAVE time rather than at RENDER time.

>I think that's what I'd do. Or perhaps store the start
date and an 
>interval. That might be best, and is supported by the
database.

>   http://www.postgresql.org/docs/current/stati
c/datatype-datetime.html

>> One direction this might lead to is a table that
stores datetimes 
>> and object references (a calendar if you will).

>You can just store an object ID.

Yeah, that's what I meant.  ID is a more accurate term.

>> Perhaps every event subelement type could reference
a calendar and 
>> when the object is saved, it publishes itself to
the calendar?  
>> Just want to make sure that whatever architecture I
end up using, 
>> it's not cutting against the Bric grain...

>I'm wary of this, but it might just be your choice of
words, since in 
>Bricolage, "publish" means to push a story
through templates and 
>distribute it to a live site. But perhaps I'm just
misunderstanding.

I think it's a shortcoming in my newbie mental model of
Bricolage.  If the underlying table that stores associations
between calendars, datetimes, and events is modified when an
event is saved, all that remains to be done is for the
calendar to be pushed through workflow again, right?  I
think that's what you're suggesting... Any suggestions as to
how to handle the workflow state of the associated calendar
when one of its events is saved?  I mean, the calendar might
be in a "live" state, but when an event is added
to the calendar, the calendar's workflow should also be
reset right?  Obviously, I need to read up on workflow so
this question is probably pre-mature given my level of
understanding.
 
Thanks.
 

On Oct 1, 2006, at 14:46, Beaudet, David P. wrote:

> Ok, I'll check it out to understand the capabilities of
 
> DateTime::Set and whether it cuts the mustard
functionally.  A nice  
> feature of Date::Manip's recurrence capabilities is
that it handles  
> virtually any type of recurring event -- (e.g. the last
day of  
> February each year, every Monday and Friday of the
second week of  
> every third month every 3 years between last January 1
and March 9  
> years from now).

I believe that DateTime can cover those, too. Post any
questions you  
have to the DateTime mail list.

   http://datetime
.perl.org/?MailingList

>> I'm wary of this, but it might just be your choice
of words, since in
>> Bricolage, "publish" means to push a
story through templates and
>> distribute it to a live site. But perhaps I'm just
misunderstanding.
>
> I think it's a shortcoming in my newbie mental model of
Bricolage.   
> If the underlying table that stores associations
between calendars,  
> datetimes, and events is modified when an event is
saved, all that  
> remains to be done is for the calendar to be pushed
through  
> workflow again, right?

Yes, and then published. Formatting templates still have to
output a  
file and distribute that file to your Web server(s).

> I think that's what you're suggesting... Any
suggestions as to how  
> to handle the workflow state of the associated calendar
when one of  
> its events is saved?  I mean, the calendar might be in
a "live"  
> state, but when an event is added to the calendar, the
calendar's  
> workflow should also be reset right?  Obviously, I need
to read up  
> on workflow so this question is probably pre-mature
given my level  
> of understanding.

I think that what you're missing is that Bricolage is not a
content  
server. It's a back-office document management and
publishing system.  
It does not serve Web sites. After a story (which, after
your  
changes, might have a calendar subelement) makes its way
through  
workflow, it gets published, which means that it is pushed
through  
formatting templates, one or more files written to disk, and
then  
those files are distributed to one or more content servers.
The nice  
thing about this is that, for example, a calendar story
might be  
pushed through HTML templates to create an HTML-based
calendar, *and*  
through ICS templates, to create an ICal file. These files
can then  
be served statically by your content server. When someone
makes a  
change to an existing story and republishes it, those static
files  
are updated on the content server(s) only the once.

Hope that helps to make things clearer.

Best,

David