[PBP-pm] Working with dates

Jay Buffington jay at mlug.missouri.edu
Wed Dec 21 13:24:29 PST 2005


> 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).

> Also, avoid offsets, as time zones with the same offsets can actually have a
> great deal of variation.
So time_zone should always be something like 'America/Los-Angeles'.
That seems strange to me, but it makes sense.

> You can return the same hash from a function (though I'd personally
> return a hash rather than a hashref) and feed it straight into
> DateTime's constructor
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();

Thanks,
Jay


On 12/21/05, Bennett Todd <bet at rahul.net> wrote:
> I'm not sure there's a one-size-fits-all best practice here.
>
> For external representations, I really like ISO 8601 / RFC 3339,
> like 2005-12-21T18:50:14Z.
>
> For many sorts of interval calculations, I'm quite happy using
> time_t (integer seconds since 1970-01-01T00:00:00Z in a POSIX
> fantasy world where leap seconds don't exist), converting printable
> => time_t with Date::Parse (from TimeDate), and back with
> Date::Format (likewise) if I need Date::Parse, POSIX::strftime if
> not.
>
> For quick one-offs, or anything where performance isn't that
> critical (i.e. I'm not doing a zillion date calculations)
> Date::Manip is comforting to have around.
>
> -Bennett
>
>
> _______________________________________________
> PBP-pm mailing list
> PBP-pm at pm.org
> http://mail.pm.org/mailman/listinfo/pbp-pm
>
>
>
>


More information about the PBP-pm mailing list