That is an option, just thought that since DateTime::Format::Strptime
already provides a function for time_zone it would make sense for all things
parsed or formatted be done in respect to that time_zone.
Like I said I already have a class that takes care of this, my own subclass
of DateTime::Format::Strptime. I was just trying to suggest the feature to
be added to DateTime::Format::Strptime itself.
When I do this:
my $Strp = new DateTime::Format::Strptime(
pattern => '%T',
locale => 'en_AU',
time_zone => 'Australia/Melbourne',
);
I expect all data in and data out (parsed and formatted) of the object $Strp
be in respect to time_zone 'Australia/Melbourne'.
I didn't want the current functionality of DateTime::Format::Strptime to
change which is why I suggested the 'format_with_time_zone' option.
If I'm way off base about this, no biggie I'll just keep using my subclass.
Just thought the feature might help more people than just me.
-Kevin
On Tue, Dec 15, 2009 at 9:40 AM, Bill Moseley <mose...@hank.org> wrote:
>
>
> On Tue, Dec 15, 2009 at 5:28 AM, Kevin McGrath <kmcgr...@baknet.com>wrote:
>
>>
>> Doing the work in parse_datetime does not work for me. In fact I almost
>> never call parse_datetime directly and when I do it's to get the datetime
>> passed in from a form into UTC. I need/want the time_zone conversion to
>> also happen within the format_datetime function when necessary.
>>
>
> Does it have to happen within the formatting? I use something like this:
>
> [% user_time( user.expire_date ).strftime( user.time_pattern || '%x %X' )
> %]
>
> Where user_time is a closure that simply does $dt->clone->set_time_zone(
> $current_user->time_zone );
>
> A VMethod would be cleaner, but I was lazy.
>
>
>
>
> --
> Bill Moseley
> mose...@hank.org
>
