[PBP-pm] Working with dates

[David Wheeler]

On Dec 21, 2005, at 1:24 PM, Jay Buffington wrote:

>> Why not just return a DateTime object?
> It sounds like the general consense is to use DateTime for most
> things, and I agree.  But, for a module that returns a date, I don't
> want to lock the user into using DateTime, since its not a standard
> module.  If they want to, great, but some uses may not need that power
> (or overhead).

You're going to find a *lot* of useful modules you'll want to use  
that aren't included with Perl. DBI is the first that comes to mind.

> So time_zone should always be something like 'America/Los-Angeles'.
> That seems strange to me, but it makes sense.

Yes, although it's "America/Los_Angeles". It may seem strange, but  
think of it this way: If you set it to +0800, what time zone is that?  
Daylight savings or standard time? These things have an effect, even  
within an offset. Offsets should be considered, at best, a rough  
approximation. The Olson database is considered the standard, IIRC.

> DateTime breaks the "Named Arguments" best practice from the PBP book
> (chapter 9, page 182).  It seems intuitive to me that the opposite
> should be true and that returning hashes is bad for similiar reasons.
> i.e. what if the users does something like this:
> my @date = get_date();

Just because a module does not adhere to the best practices laid out  
in the book (if for no other reason than that it pre-dates the book  
by several years), that does not make it a bad module. Indeed, there  
are very good reasons to argue that a list is a better practice than  
a hash, and I believe that Dave Rolsky holds to those reasons. But  
from your POV, it just makes the use of the module a bit different  
than the use of other modules you write yourself.

It's more important to use a module as a best practice than to not  
use it because it does not adhere to some defined set of best practices.

Best,

David (Theory)