Re: Rough first draft of a FAQ

2003-06-02 Thread Dave Rolsky
On Fri, 30 May 2003, Ben Bennett wrote:

 On Fri, May 30, 2003 at 12:36:17PM -0500, Dave Rolsky wrote:
 
  The archives are linked on the mailing list page and the modules page has
  links to each module's CPAN page.

 OK.  At the very least I want to leave a link to the top of
 datetime.perl.org in case they came in using a link fron elsewhere
 (e.g. google).

Well, my plan was to integrate it into the site directly, so that the look
and feel is the same, and the left menu is still present.

 I will probably leave the tip for how to search the archives with
 google unless you are strongly opposed.

That's fine.

 How do you want to progress from here... I will try and get the TODO
 items cleaned up and have a look at the grouping and ordering.  At
 some point I should get CVS access and commit the stuff.

I can give you CVS access now and you can stick it under a top-level FAQ
directory.  Email me your sourceforge username.


-dave

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


Re: Rough first draft of a FAQ

2003-05-31 Thread Ben Bennett
On Fri, May 30, 2003 at 12:36:17PM -0500, Dave Rolsky wrote:

 The archives are linked on the mailing list page and the modules page has
 links to each module's CPAN page.

OK.  At the very least I want to leave a link to the top of
datetime.perl.org in case they came in using a link fron elsewhere
(e.g. google).

I will probably leave the tip for how to search the archives with
google unless you are strongly opposed.


How do you want to progress from here... I will try and get the TODO
items cleaned up and have a look at the grouping and ordering.  At
some point I should get CVS access and commit the stuff.

-ben


Re: Rough first draft of a FAQ

2003-05-31 Thread Dan Sully
* Ben Bennett [EMAIL PROTECTED] shaped the electrons to say...

 I have a (very) rough draft of a faq available at:
   http://www.limey.net/~fiji/perl/

Ben - I like the FAQ a lot. A suggestion though - you offer quite a few
functions that do useful things, ie: get_day_in_same_week, etc.

It'd be useful (to me at least) if those made it into a DateTime::Helpers or somesuch.

-D
--
I'm riding my bicycle 600 miles to fight AIDS! 
I've raised $1850 out of a minimum $2500 so far!
Sponsor me at: http://electricrain.com/daniel/lifecycle/sponsor/


Re: Rough first draft of a FAQ

2003-05-31 Thread Dave Rolsky
On Fri, 30 May 2003, Dan Sully wrote:

 * Ben Bennett [EMAIL PROTECTED] shaped the electrons to say...

  I have a (very) rough draft of a faq available at:
http://www.limey.net/~fiji/perl/

 Ben - I like the FAQ a lot. A suggestion though - you offer quite a few
 functions that do useful things, ie: get_day_in_same_week, etc.

 It'd be useful (to me at least) if those made it into a DateTime::Helpers or 
 somesuch.

Or maybe just into the core.  I'm open to adding more methods, as long as
they provide something useful that people would otherwise end up
re-implementing in their own code.


-dave

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


Re: Rough first draft of a FAQ

2003-05-31 Thread Flavio S. Glock
Dave Rolsky wrote: 
 Or maybe just into the core.  I'm open to adding more methods, as long as
 they provide something useful that people would otherwise end up
 re-implementing in their own code.

I use something like 'truncate( to = sunday )' inside
DT::E::Recurrence. Does it make sense for somebody else?

- Flavio S. Glock


Re: Rough first draft of a FAQ

2003-05-31 Thread Ben Bennett
I would not be opposed, but I think we should let the FAQ settle a bit
before rolling stuff into the core.

Some of the items are really the DT::Business that Dave mentioned
earlier.

Perhaps others belong in DT itself or in DT::Calc.

One reason that I sort of think the latter is that you want to be able
to define what a week is.  You may be using the ISO week (which may be
in a different year) or a different start day for the week (e.g. Saudi
Arabia has the weekend on Friday and Saturday, I dunno if that is
common in other Islamic countries).  So you need a way to set that
calculation wide, so you may need to do something like:

use DT::Calc qw(:constants);

my $calc = DT::Calc-new(week_starts_with = MONDAY);
$calc-get_day_in_same_week($dt, THURSDAY);

or somesuch.  The sub names are pretty ugly so I am open to
suggestions for better ones.

 -ben


On Fri, May 30, 2003 at 01:46:57PM -0500, Dave Rolsky wrote:
 On Fri, 30 May 2003, Dan Sully wrote:
 
  * Ben Bennett [EMAIL PROTECTED] shaped the electrons to say...
 
   I have a (very) rough draft of a faq available at:
 http://www.limey.net/~fiji/perl/
 
  Ben - I like the FAQ a lot. A suggestion though - you offer quite a few
  functions that do useful things, ie: get_day_in_same_week, etc.
 
  It'd be useful (to me at least) if those made it into a DateTime::Helpers or 
  somesuch.
 
 Or maybe just into the core.  I'm open to adding more methods, as long as
 they provide something useful that people would otherwise end up
 re-implementing in their own code.
 
 
 -dave
 
 /*===
 House Absolute Consulting
 www.houseabsolute.com
 ===*/


Re: Rough first draft of a FAQ

2003-05-30 Thread Rick Measham
Looking through the FAQ (thanks Ben!), the question about comparisons is
raised. Clearly DT-now is only == to DT-today for one nanosecond.

Maybe we should add a routine such as the following to the core?

sub same {
$_[0]-clone-truncate(to=$_[1]) == $_[2]-clone-truncate(to=$_[0]);
}

this lets us say things like:

if (same($dt1,'day',$dt2)) { ... }

Or, if you want to use it as an object method:

if ($dt1-same('day',$dt2)) { ... }

Then there'd also be similar versions of gt, lt and cmp:
sub greater {
$_[0]-clone-truncate(to=$_[1])  $_[2]-clone-truncate(to=$_[0]);
}
sub lesser {
$_[0]-clone-truncate(to=$_[1])  $_[2]-clone-truncate(to=$_[0]);
}
sub compare { # Written quick, there could be a better way!
return 1 if $_[0]-greater($_[1],$_[2]);
return -1 if $_[0]-lesser($_[1],$_[2]);
return 0;
}

Note: I use 'same' rather than 'equal' as the two objects aren't 'equal' but
they do share the 'same' day.

Cheers!
Rick



Re: Rough first draft of a FAQ

2003-05-30 Thread Dave Rolsky
On Fri, 30 May 2003, Ben Bennett wrote:

 The general structure of the page is quite likely to change (as are
 the question numbers).  I plan on adding more sections and reordering
 the existing questions, but I wanted to get feedback first.

It generally looks great.

 If people could propose additional questions for the FAQ (if you
 provide answers that would be even better), provide code
 suggestions and answer any QUESTIONs I have that would be fantastic.

First I'll pick some nits.

- Assume it will be hosted on datetime.perl.org, so you can skip the first
4 questions.

- Please don't use fixed number offsets for the time zone examples.  This
only encourages broken code when people do this in real apps when instead
they should use a named time zone.


Now to answer specific questions:

2.3: Why do I need to truncate dates?

QUESTION Is it worthwhile to add an optional resolution argument to
compare to allow easier usage?

Maybe.  My theory is that most people will take advantage of overloading
and just use Perl's built-in comparison operators.


2.4: What is the floating time zone?

QUESTION Should compare_ignore_floating take an optional timezone
argument? (See also the possible argument for resolution...)

I think the section of the floating time zone should have a big fat
warning that mixing floating time zones and real time zones is likely to
lead to a mess.  The floating time zone option exists for people who want
to abstract datetime stuff.  Mixing it with actual time zones, unless
you really understand why you're doing so, is bound to lead to trouble.

All of which doesn't answer your question, but the point is I don't want
to make mixing floating  non-floating so easy that people don't think
twice before doing so.


2.21: How can I calculate the last business day (payday!) of a month?

QUESTION: Do we do anything with business logic?

No, I'm waiting for someone to writing a DateTime::Business module.  Any
takers?


2.27: How can I calculate the difference in days between dates, but
without counting Saturdays and Sundays?

QUESTION: Is the best way to do this simply to make a DateTime::Set and
loop over it?

See above ;)




-dave

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


Re: Rough first draft of a FAQ

2003-05-30 Thread Rick Measham
On 30/5/03 2:39 PM, Rick Measham at [EMAIL PROTECTED] spake thus:
 Looking through the FAQ (thanks Ben!), the question about comparisons is
 raised. Clearly DT-now is only == to DT-today for one nanosecond.
 
 Maybe we should add a routine such as the following to the core?

Second thoughts here: Maybe we should create a module DateTime::Utilities ..
or a namespace for it and write DateTime::Utilities::Compare?

Thoughts?

Cheers!
Rick



Re: Rough first draft of a FAQ

2003-05-30 Thread Bruce Van Allen
On Thursday, May 29, 2003, at 09:39  PM, Rick Measham wrote:

Looking through the FAQ (thanks Ben!), the question about comparisons 
is
raised. Clearly DT-now is only == to DT-today for one nanosecond.

Maybe we should add a routine such as the following to the core?

sub same {
$_[0]-clone-truncate(to=$_[1]) == 
$_[2]-clone-truncate(to=$_[0]);
}
I think you meant:

   $_[0]-clone-truncate(to=$_[1]) == 
$_[2]-clone-truncate(to=$_[1])
  ^
this lets us say things like:

if (same($dt1,'day',$dt2)) { ... }
Eew.

Or, if you want to use it as an object method:

if ($dt1-same('day',$dt2)) { ... }
- What about testing more than two DT objects at a time?
- What is same? Basing it on truncate wouldn't allow testing for 
things like the same hour on different dates.
- I'm not opposed to something like a DT::Utilities module, as your 
next post mentions, but this could become a catch-all for a bunch of 
hacks that add cruft or that veer off the DT API when the powers of DT 
are sufficient.
- Isn't this pretty useful as is?
  if ($dt1-day == $dt2-day) { ... }
  if ($dt1-day_of_week == $dt2-day_of_week) { ... }

Maybe there are some other examples that show how same() would be 
usefully implemented?

Also, thanks, Ben!

  - Bruce

__bruce__van_allen__santa_cruz__ca__



Re: Rough first draft of a FAQ

2003-05-30 Thread Ben Bennett
On Thu, May 29, 2003 at 11:59:21PM -0500, Dave Rolsky wrote:

 First I'll pick some nits.
 
 - Assume it will be hosted on datetime.perl.org, so you can skip the first
 4 questions.

I dunno, 1.1 to govern the scope of the FAQ seemes relevant as does
the reference to Claus' FAQ in 1.3.  I haven't seen 1.4 (searching)
anywhere but as a post to the list itself (which reminds me, I should
use the search to see who suggested that method).

Are we sure that datetime.perl.org will be the only place for the FAQ?
Will it be distributed with the module ever?

Should I add a section on how to install it?

Anyway, I will revise it given the assumption that it is on
datetime.perl.org.

 
 - Please don't use fixed number offsets for the time zone examples.  This
 only encourages broken code when people do this in real apps when instead
 they should use a named time zone.

Fair enough.  I had that originally, but thought it was more clear
with explicit numbers.  I will change it.  (BTW the DateTime POD uses
offsets when explaining set_time_zone)


 Now to answer specific questions:
 
 2.3: Why do I need to truncate dates?
 
 QUESTION Is it worthwhile to add an optional resolution argument to
 compare to allow easier usage?
 
 Maybe.  My theory is that most people will take advantage of overloading
 and just use Perl's built-in comparison operators.

Agreed, but when you want to compare things at a different resolution
now you may have to:
--
$dt1 = $dt1-clone()-truncate(to = 'day');
$dt2 = $dt2-clone()-truncate(to = 'day');
if ($dt1 = $dt2) { ... }
--

Rather than:
$dt1-compare($dt2, {to = 'day'});

Admittedly the second is way more ugly if you need to do lots of
comparisons with the dates, but the case I think it is a big win is
with sorting since you can just use the resolution argument in the
comparator without having to (possibly) clone and truncate the dates
in the original sort list.

 2.4: What is the floating time zone?
 
 QUESTION Should compare_ignore_floating take an optional timezone
 argument? (See also the possible argument for resolution...)
 
 I think the section of the floating time zone should have a big fat
 warning that mixing floating time zones and real time zones is likely to
 lead to a mess.  The floating time zone option exists for people who want
 to abstract datetime stuff.  Mixing it with actual time zones, unless
 you really understand why you're doing so, is bound to lead to trouble.
 
 All of which doesn't answer your question, but the point is I don't want
 to make mixing floating  non-floating so easy that people don't think
 twice before doing so.

Fair enough.  Added the warning.

 2.21: How can I calculate the last business day (payday!) of a month?
 
 QUESTION: Do we do anything with business logic?
 
 No, I'm waiting for someone to writing a DateTime::Business module.  Any
 takers?

Mebbe.  I have learned quite a bit about the modules from writing the
FAQ.

-ben