There is nothing I want to do with parse_datetime. parse_datetime works
great and nothing I have said suggests that anything different should happen
when parsing a string to a datetime object. Everything about
parse_datetime, reading of a string and setting of a time_zone works exactly
how anyone
On Tue, Dec 15, 2009 at 11:39 PM, Evan Carroll wrote:
> How much would you want to be overridable, and set in the constructor
> of the DateTime::Format module?
Just the format_datetime function when it comes to the value which is
assigned to the time_zone attribue. It's already an attribute of
Maybe that's what I'm really looking for. I originally thought it was a
minor change that fit well within the parameters of the current module, but
I'm open to ideas.
-Kevin
On Tue, Dec 15, 2009 at 5:25 PM, Jim Monty wrote:
> How about an entirely new, high-level abstraction layer: DateTime::E
On Tue, Dec 15, 2009 at 6:51 PM, Evan Carroll wrote:
> > Why then does parse_datetime automatically convert from a string to a
> > timezone?
> > Shouldn't it then just always return a datetime in floating context?
>
> It doesn't "convert" it "reads it as".
>
> > my $dt = $Strp->parse_datetime($my
On Tue, Dec 15, 2009 at 5:01 PM, Evan Carroll wrote:
> On Tue, Dec 15, 2009 at 3:39 PM, Kevin McGrath
> wrote:
> > I guess I'm just not very good at explaining the feature. If I have a
> > formatter that is related to a time_zone then I feel that input and
> output
&g
I guess I'm just not very good at explaining the feature. If I have a
formatter that is related to a time_zone then I feel that input and output
of that formatter should be able to be based on that time zone.
my $Strp = new DateTime::Format::Strptime(
pattern => '%T',
locale => 'en_AU'
ested 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.
On Tue, Dec 15, 2009 at 4:01 PM, Evan Carroll wrote:
> On Tue, Dec 15, 2009 at 7:28 AM, Ke
f 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 wrote:
>
>
> On Tue, Dec 15, 2009 at 5:28 AM, Kevin McGrath wrote:
>
>>
>> Doi
Here is my situation. I use the Rose Framework as my ORM under mod_perl,
fast_cgi, and server_side scripts. I have the framework set up to use UTC
to store all datetimes. I do all work in my controllers in UTC time. The
majority of the time I need a datetime to be converted to a specific
time_z
DateTime::Event::Recurrence works just like a DateTime::Set. It inherits
the as_list function from DateTime::Set which you could use:
use DateTime;
use DateTime::Event::Recurrence;
use strict;
my $dt = DateTime->now();
$dt->set(hour=>0, minute=>0, second=>0, day=>1);
my $weekly_set = DateTime
The time_zone function in DateTime::Format::Strptime is only called with
parse_datetime. I think a nice feature would be to also set the time_zone
when calling format_datetime.
I have my own subclass which does this now, but find myself using this more
and more in a lot of different projects. I
11 matches
Mail list logo