Date/Time type announcement
http://www.python.org/doc/2.3/whatsnew/node18.html#SECTION0001810000000000000000

'DateTime' Object
http://www.python.org/doc/2.3/lib/module-datetime.html

Gregorian Calendar from Calendrical Calculations that requires 'DateTime'
http://www.python.org/doc/2.3/lib/module-calendar.html

'Duration' Object
http://www.python.org/doc/2.3/lib/datetime-timedelta.html

'TimeZone' Object (complete with the EST timezone)
http://www.python.org/doc/2.3/lib/datetime-tzinfo.html

'Incomplete' Date/Time Object
http://www.python.org/doc/2.3/lib/datetime-date.html

'Strftime'
http://www.python.org/doc/2.3/lib/node208.html

-J

--

> Date/Time type announcement
> http://www.python.org/doc/2.3/whatsnew/node18.html#SECTION0001810000000000000000
>
> 'DateTime' Object
> http://www.python.org/doc/2.3/lib/module-datetime.html
>
> Gregorian Calendar from Calendrical Calculations that requires 'DateTime'
> http://www.python.org/doc/2.3/lib/module-calendar.html
>
> 'Duration' Object
> http://www.python.org/doc/2.3/lib/datetime-timedelta.html
>
> 'TimeZone' Object (complete with the EST timezone)
> http://www.python.org/doc/2.3/lib/datetime-tzinfo.html
>
make that

'Incomplete' Date/Time Objects
http://www.python.org/doc/2.3/lib/datetime-date.html
http://www.python.org/doc/2.3/lib/datetime-time.html

>
> 'Strftime'
> http://www.python.org/doc/2.3/lib/node208.html

-J

--

On Tue, 29 Jul 2003, Joshua Hoblitt wrote:

> 'DateTime' Object
> http://www.python.org/doc/2.3/lib/module-datetime.html

No leap seconds.  Years 1 - 9999 only! (why?!).  microsecond resolution.

> Gregorian Calendar from Calendrical Calculations that requires 'DateTime'
> http://www.python.org/doc/2.3/lib/module-calendar.html

Sort of Gregorian, also a grab bag of random stuff, like monthcalendar,
which returns a matrix representing a month's calendar.

Actually, that latter bit is kind of neat.  Wonder if we need it.

> 'Duration' Object
> http://www.python.org/doc/2.3/lib/datetime-timedelta.html

No support for months in durations.  lame.

> 'TimeZone' Object (complete with the EST timezone)
> http://www.python.org/doc/2.3/lib/datetime-tzinfo.html

Bleah.  This is just an interface.  There's no implementation included,
though last I looked somebody had implemented something that did the _most
recent_ rules, ignoring all historical changes.

> 'Incomplete' Date/Time Object
> http://www.python.org/doc/2.3/lib/datetime-date.html

Sort of.

> 'Strftime'
> http://www.python.org/doc/2.3/lib/node208.html



They suck, we rule.


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

> They suck, we rule.

I forgot the 'for entertainment purposes only' disclaimer. :)

-J

--

Just to be clear - I intended this to be humorous.  I was not truly equating that 'stuff' to one true DateTime {TM}. :)

Cheers,

-J

--
On Tue, 29 Jul 2003, Joshua Hoblitt wrote:

> > Date/Time type announcement
> > http://www.python.org/doc/2.3/whatsnew/node18.html#SECTION0001810000000000000000
> >
> > 'DateTime' Object
> > http://www.python.org/doc/2.3/lib/module-datetime.html
> >
> > Gregorian Calendar from Calendrical Calculations that requires 'DateTime'
> > http://www.python.org/doc/2.3/lib/module-calendar.html
> >
> > 'Duration' Object
> > http://www.python.org/doc/2.3/lib/datetime-timedelta.html
> >
> > 'TimeZone' Object (complete with the EST timezone)
> > http://www.python.org/doc/2.3/lib/datetime-tzinfo.html
> >
> make that
>
> 'Incomplete' Date/Time Objects
> http://www.python.org/doc/2.3/lib/datetime-date.html
> http://www.python.org/doc/2.3/lib/datetime-time.html
>
> >
> > 'Strftime'
> > http://www.python.org/doc/2.3/lib/node208.html
>
> -J
>
> --
>

In article <Pine.LNX.4.56.0307292310480.30012@urth.org>,
 autarch@urth.org (Dave Rolsky) wrote:
> > Gregorian Calendar from Calendrical Calculations that requires 'DateTime'
> > http://www.python.org/doc/2.3/lib/module-calendar.html
> 
> Sort of Gregorian, also a grab bag of random stuff, like monthcalendar,
> which returns a matrix representing a month's calendar.
> 
> Actually, that latter bit is kind of neat.  Wonder if we need it.

Months ago I posted the beginings of a module that I called 
DateTime::Format::Calendar. The discussion that followed was that 
'format' was the wrong namespace, but the conversation ended there.
 (http://nntp.x.perl.org/group/perl.datetime/2488)

I'm happy to continue working on this, and will upload it somewhere, but 
I need a name.

Cheers!
Rick 

(rickmeasham@optusnet.com.au)
(rickm@printaform.com.au)
(rickm@isite.net.au is not working)

> Months ago I posted the beginings of a module that I called
> DateTime::Format::Calendar. The discussion that followed was that
> 'format' was the wrong namespace, but the conversation ended there.
>  (http://nntp.x.perl.org/group/perl.datetime/2488)
>
> I'm happy to continue working on this, and will upload it somewhere, but
> I need a name.

DateTime::Calendar::Gregorian::Month?

-J

--

DateTime::Display::Calendar or
DateTime::Display::Calendar::Text (vs. HTML, etc.)

?

		       -ben


On Tue, Jul 29, 2003 at 10:46:59PM -1000, Joshua Hoblitt wrote:
> > Months ago I posted the beginings of a module that I called
> > DateTime::Format::Calendar. The discussion that followed was that
> > 'format' was the wrong namespace, but the conversation ended there.
> >  (http://nntp.x.perl.org/group/perl.datetime/2488)
> >
> > I'm happy to continue working on this, and will upload it somewhere, but
> > I need a name.
> 
> DateTime::Calendar::Gregorian::Month?
> 
> -J
> 
> --

> DateTime::Display::Calendar or
> DateTime::Display::Calendar::Text (vs. HTML, etc.)

In this context display has the same meaning as format.  It seems that we are struggling with a namespace for utility classes.  Initially I proposed DT::Wrapper (which Dave likes) but I've also suggested DT::Util as both decorator and delegatee classes could live there.

Rick - Can this code be used with non-Gregorian calendars?

-J

--

From: jhoblitt[at]ifa.hawaii.edu (Joshua Hoblitt)
> > DateTime::Display::Calendar or
> > DateTime::Display::Calendar::Text (vs. HTML, etc.)
> 
> In this context display has the same meaning as format.  It seems that
> we are struggling with a namespace for utility classes.  Initially I
> proposed DT::Wrapper (which Dave likes) but I've also suggested
> DT::Util as both decorator and delegatee classes could live there.
> 
> Rick - Can this code be used with non-Gregorian calendars?


Can't remember if it can or not, although it would just be a case of
implementing it. Basically you give it a start and end datetime, and
then select a render style or create your own.

Render styles can be anything: Postscript, HTML, plain text. They can
have as many or as few days in each grid line as needed: Gregorian month
would be a 7 x 5 grid (with a wrap) or 7 x 6 without a wrap. But a
week-at-a-glance calendar would only be one day wide.

If some other calendar had a 5 day week, then that'd just be different
render style. The underlying functionality would just use whatever class
it was given.

On Namespace:

While I understand DateTime::Display::Calendar, it's probably not a
namespace that would have much more in it.

DateTime::Util seems to make more sense, but I'd suggest maybe
DateTime::App could be a better namespace for all end-uses of DateTime,
including ways to display a Datetime.

Cheers!
Rick

It was Wednesday, July 30, 2003 when Ben Bennett took the soap box, saying:
: DateTime::Display::Calendar or
: DateTime::Display::Calendar::Text (vs. HTML, etc.)

DateTime::Display::Calendar

Wouldn't it, in the most simple form, just return the data structure
matrix?  No text, no HTML, just data.

  Casey West

-- 
By the time (the Leaning Tower of Pisa) was 10% built, everyone knew
it would be a total disaster. But the investment was so big they felt
compelled to go on. Since its completion, it cost a fortune to
maintain and is still in danger of collapsing. There are no plans to
replace it, since it was never needed in the first place. I expect
every installation has its own pet software which is analogous to the
above. -- Ken Iverson

Your suggested namespaces make sense.

I would love to be able to have holidays, phases of the moon,
etc. displayed on the calendar...  Perhaps some mechanism to provide
additional information would be in order?

-ben

On Wed, Jul 30, 2003 at 11:25:10PM +1000, Rick Measham wrote:
> From: jhoblitt[at]ifa.hawaii.edu (Joshua Hoblitt)
> > > DateTime::Display::Calendar or
> > > DateTime::Display::Calendar::Text (vs. HTML, etc.)
> > 
> > In this context display has the same meaning as format.  It seems that
> > we are struggling with a namespace for utility classes.  Initially I
> > proposed DT::Wrapper (which Dave likes) but I've also suggested
> > DT::Util as both decorator and delegatee classes could live there.
> > 
> > Rick - Can this code be used with non-Gregorian calendars?
> 
> 
> Can't remember if it can or not, although it would just be a case of
> implementing it. Basically you give it a start and end datetime, and
> then select a render style or create your own.
> 
> Render styles can be anything: Postscript, HTML, plain text. They can
> have as many or as few days in each grid line as needed: Gregorian month
> would be a 7 x 5 grid (with a wrap) or 7 x 6 without a wrap. But a
> week-at-a-glance calendar would only be one day wide.
> 
> If some other calendar had a 5 day week, then that'd just be different
> render style. The underlying functionality would just use whatever class
> it was given.
> 
> On Namespace:
> 
> While I understand DateTime::Display::Calendar, it's probably not a
> namespace that would have much more in it.
> 
> DateTime::Util seems to make more sense, but I'd suggest maybe
> DateTime::App could be a better namespace for all end-uses of DateTime,
> including ways to display a Datetime.
> 
> Cheers!
> Rick

> DateTime::Display::Calendar
>
> Wouldn't it, in the most simple form, just return the data structure
> matrix?  No text, no HTML, just data.

In that case it wouldn't be displaying anything. :)

I really think that 'Display' is too easily confused with 'Format'.  Looking at synonyms for 'Display' I've come up with 'Presentation'.  Which I like because it make it very clear that a transformation is being made.

The base class would be:

DateTime::Presentation

The styles would be:

DateTime::Presentation::HTML
DateTime::Presentation::LateX
DateTime::Presentation::PS
..
..

The default mode would be Gregorian but we should make it simple to present for other Calendars.  Either by requiring calendar classes to contain meta data describing their structure or having encoding more information into the DT::Presentation namespace.

DateTime::Presentation::Calendar::Mayan
DateTime::Presentation::Calendar::Egyptian
..
..

To get a HTML version of the Gregorian year 2003:

--
use DateTime;
use DateTime::Span;
use DateTime::Presentation::HTML

my $dt1 = DateTime->new( year => 2003, month => 1, day => 1 );
my $dt2 = DateTime->new( year => 2003, month => 12, day => 31 );
my $range = DateTime::Span->from_datetimes( start => $dt1, end => $dt2 );

my $dthtml = DateTime::Presentation::HTML->from_set( $range );

$dthtml->dump;
--

To get a HTML version of a Mayan uinal:

--
use DateTime::Calendar::Mayan;
use DateTime::Span;
use DateTime::Presentation::HTML

my $dt1 = DateTime::Calendar::Mayan->new( ;
		baktun  => 12,
		katun   => 19,
		tun     => 10,
		uinal   => 2,
		kin     => 0,
	);
my $dt2 = DateTime::Calendar::Mayan->new( ;
		baktun  => 12,
		katun   => 19,
		tun     => 10,
		uinal   => 2,
		kin     => 19,
	);
my $range = DateTime::Span->from_datetimes( start => $dt1, end => $dt2 );

my $dthtml = DateTime::Presentation::HTML->from_set( $range );

# looks under DateTime::Presentation::Calendar::
$dthtml->calendar( 'Mayan' );

$dthtml->dump;
--

Cheers,

-J

--

In article <20030730180840.GA20295@ayup.limey.net>,
 fiji@ayup.limey.net (Ben Bennett) wrote:

> Your suggested namespaces make sense.
> 
> I would love to be able to have holidays, phases of the moon,
> etc. displayed on the calendar...  Perhaps some mechanism to provide
> additional information would be in order?

Yup, I think that's already in there ... and you can feed in whatever, 
such as appointments. It doesn't do any colision checks, that's for the 
end user. All this does is present the framework from data.

Cheers!
Rick

> The default mode would be Gregorian but we should make it simple to present for other Calendars.  Either by requiring calendar classes to contain meta data describing their structure or having encoding more information into the DT::Presentation namespace.
>
> DateTime::Presentation::Calendar::Mayan
> DateTime::Presentation::Calendar::Egyptian

Or better yet:

DateTime::Calendar::Mayan::Presentation that would be bundled with the calendar.

> To get a HTML version of the Gregorian year 2003:
>
> --
> use DateTime;
> use DateTime::Span;
> use DateTime::Presentation::HTML
>
> my $dt1 = DateTime->new( year => 2003, month => 1, day => 1 );
> my $dt2 = DateTime->new( year => 2003, month => 12, day => 31 );
> my $range = DateTime::Span->from_datetimes( start => $dt1, end => $dt2 );
>
> my $dthtml = DateTime::Presentation::HTML->from_set( $range );

$dthtml->event( from_datetime => $somedt, description => 'something at sometime' );

$dthtml->event( from_set => $someset, description => 'some recurring event' );

$dthtml->event( from_set => $someotherset, description => 'event spanning sometime' );

> $dthtml->dump;
> --

-J

--

On Wed, 30 Jul 2003, Joshua Hoblitt wrote:

> $dthtml->event( from_datetime => $somedt, description => 'something at sometime' );
>
> $dthtml->event( from_set => $someset, description => 'some recurring event' );
>
> $dthtml->event( from_set => $someotherset, description => 'event spanning sometime' );

I suspect that things like descriptions should be attached to the set or
datetime, then we can tell the presenter which things to pull from the
set/datetime.

I tried to do this for DateTime.pm a while back, but there were lots of
problems with it, because if the DateTime object mutates, the attached
"extra" data may no longer be correct.

Coming up with a way to handle this would be nice ;)


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

At 8:13 PM -0500 30/7/03, Dave Rolsky wrote:
>I suspect that things like descriptions should be attached to the set or
>datetime, then we can tell the presenter which things to pull from the
>set/datetime.
>
>I tried to do this for DateTime.pm a while back, but there were lots of
>problems with it, because if the DateTime object mutates, the attached
>"extra" data may no longer be correct.
>
>Coming up with a way to handle this would be nice ;)


The 'Simple' version of DateTime::Decorator::Data (or whatever!)

$dt = DateTime->now();

$dt->set_immutable("31", "July");
$dt->set_mutable("Random Date");

print join("\n",$dt->data);
	31
	July
	Random Date

print join("\n",$dt->immutable_data);
	31
	July

print join("\n",$dt->mutable_data);
	Random Date



$dt->add( days => 1 );

print join("\n",$dt->data);
	Random Date

print join("\n",$dt->immutable_data);
	# Empty

print join("\n",$dt->mutable_data);
	Random Date




The 'Extended' version:
(with a 'degree of mutablilty')

$dt = DateTime->now();

$dt->set_immutable_within( span=>$today_as_span, data=>["31", "July"]);
$dt->set_immutable_within( span=>$thursdays_as_spanset, data=>["Thursday"]);

print join("\n",$dt->data);
	31
	July
	Thursday

$dt->add( hours => 1 ); # Still July 31

print join("\n",$dt->data);
	31
	July
	Thursday

# Example 1
$dt->add( days => 1 ); # Not July 31, not Thursday

print join("\n",$dt->data);
	# Empty

# Example 2
$dt->add( days => 7 ); # Not July 31, but Thursday nonetheless

print join("\n",$dt->data);
	Thursday



-- 
--------------------------------------------------------
             There are 10 kinds of people:
   those that understand binary, and those that don't.
--------------------------------------------------------
   The day Microsoft makes something that doesn't suck
     is the day they start selling vacuum cleaners
--------------------------------------------------------
"Write a wise proverb and your name will live forever."
    -- Anonymous
--------------------------------------------------------

>  > The default mode would be Gregorian but we should make it simple 
>to present for other Calendars.  Either by requiring calendar 
>classes to contain meta data describing their structure or having 
>encoding more information into the DT::Presentation namespace.
>>
>  > DateTime::Presentation::Calendar::Mayan
>>  DateTime::Presentation::Calendar::Egyptian
>
>Or better yet:
>
>DateTime::Calendar::Mayan::Presentation that would be bundled with 
>the calendar.

The module doesn't care what calendar you're using. It just uses a 
render style. The standard render style for they mayan calendar would 
be stored in:
	DateTime::Presentation::Mayan

And if someone wanted a special diary format for their Mayan Appointment book:
	DateTime::Presentation::MayanDiary

And as you say, I can see this presentation style being bundled with 
the Mayan calendar module. The beauty of this system is that I can 
publicise my diary (where I enter events in Gregorian), and then you 
can view it in Mayan!

>  > To get a HTML version of the Gregorian year 2003:
>>
>>  --
>>  use DateTime;
>>  use DateTime::Span;
>>  use DateTime::Presentation::HTML
>>
>>  my $dt1 = DateTime->new( year => 2003, month => 1, day => 1 );
>>  my $dt2 = DateTime->new( year => 2003, month => 12, day => 31 );
>>  my $range = DateTime::Span->from_datetimes( start => $dt1, end => $dt2 );
>>
>>  my $dthtml = DateTime::Presentation::HTML->from_set( $range );
>
>$dthtml->event( from_datetime => $somedt, description => 'something 
>at sometime' );

Does this already

>$dthtml->event( from_set => $someset, description => 'some recurring event' );
>$dthtml->event( from_set => $someotherset, description => 'event 
>spanning sometime' );


Added to Todo


>  > $dthtml->dump;


Actually $dthtml->render;

Further applications of the module would care about colision events, 
event classes and extracting the events as spansets. This module is 
just about the presentation. Give it two events at 11am today and it 
will just render with both of them listed.

Cheers!
Rick

-- 
--------------------------------------------------------
             There are 10 kinds of people:
   those that understand binary, and those that don't.
--------------------------------------------------------
   The day Microsoft makes something that doesn't suck
     is the day they start selling vacuum cleaners
--------------------------------------------------------
"Write a wise proverb and your name will live forever."
    -- Anonymous
--------------------------------------------------------

> I suspect that things like descriptions should be attached to the set or
> datetime, then we can tell the presenter which things to pull from the
> set/datetime.

Maybe something like:

$dt :event( description => "..." );

?

> I tried to do this for DateTime.pm a while back, but there were lots of
> problems with it, because if the DateTime object mutates, the attached
> "extra" data may no longer be correct.

I can't think of a nice way to handle that.  I suppose a change could remove the event data but that would add overhead to every mutator method (ick!).  Another idea would be to add some sort of immutable flag that would cause a croak if the blessed object was changed.

$dt :locked :event( description => "..." );

?

-J

--

> Further applications of the module would care about colision events,
> event classes and extracting the events as spansets. This module is
> just about the presentation. Give it two events at 11am today and it
> will just render with both of them listed.

A long term goal might be ICAL -> DT::Presentation -> ICAL. :)

-J

--

> The 'Simple' version of DateTime::Decorator::Data (or whatever!)

This brings up the point that we still haven't come up with a infrastructure so multiple decorators can be combined.

-J

--

Joshua Hoblitt wrote:
> I really think that 'Display' is too easily confused with 'Format'.  Looking at synonyms for 'Display' I've come up with 'Presentation'.  Which I like because it make it very clear that a transformation is being made.

How about 'View' ?

Matt