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
