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 would expect. So again parse_datetime is 100% OK, nothing should
change about it at all.
My suggestion was simply if parse_datetime sets the value of your string to
a specific time_zone why can't format_datetime. I showed earlier that the
time_zone parameter when passed to the constructor of Format:: already
overrides any time zone that may be pulled from the string. What is
returned from parse_datetime is a datetime object that is constructed with
the time_zone parameter provided.
When format_datetime is called it uses the pattern and the locale from the
Format:: constructor to do it's job:
sub format_datetime {
my ( $self, $dt ) = @_;
my $pattern = $self->pattern;
$pattern =~ s/%O/$dt->time_zone->name/eg;
return $dt->clone->set_locale($self->
locale)->strftime($pattern);
}
The $dt object you pass in currently has it's locale changed. Thats a
parameter passed to the constructor of Format:: used for both constructing a
datetime object and for formatting a datetime object. If I pass in a $dt to
format_datetime with a locale of en_AS and the constructor of Format:: has
locale set to en_US format_datetime clones my object sets the locale then
returns the pattern.
All I'm purposing is something like this:
sub format_datetime {
my ( $self, $dt ) = @_;
my $pattern = $self->pattern;
$pattern =~ s/%O/$dt->time_zone->name/eg;
my $clone_dt = $dt->clone;
if ($self->format_with_time_zone) {
return
$clone_dt->set_locale($self->locale)->set_time_zone($self->time_zone)->strftime($pattern);
}
return $clone_dt->set_locale($self->locale)->strftime($pattern);
}
No crazy math. Just setting the time_zone of the object to be the time_zone
of the Format:: constructor in the same way locale is done.
If you have a DateTime based on epoch 1260967863 then all of the following
are representations of that epoch time:
12/16/09 12:51:03 UTC
12/16/09 07:51:03 EST
12/16/09 06:51:03 CST
12/16/09 13:51:03 CET
They all reference the same point in time. They are just formatted
different for the convenience of those who wish to read times based on a
particular time_zone. Nothing is being done to change the point in time of
the object. All you are doing is formatting datetime object so it makes
sense as a string. Nothing that produces the formatted string should change
the point in time the object represented originally. Neither locale or
time_zone alter the point in time that is being represented by a string.
-Kevin
On Wed, Dec 16, 2009 at 2:40 AM, Evan Carroll <m...@evancarroll.com> wrote:
> > 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 the
> > module.
>
> I simply /do not/ believe you understand the difference between being
> 1:30 "read-in the context of" America/Chicago, and "converting it with
> date-math" to the timezone of America/Chicago. The constructor
> argument has /nothing at all/ to do with what your wanting (date-math
> convenience).
>
> >> Here is better API idea, why not just make the hash ref to
> >> format_datetime, a huge method wrapper!!!!
> >
> > Taken to the point of absurdity.
>
> But why not? If your goal is simply to provide a convenience wrapper
> that is capable of doing the date-math through DateTime, then why not
> permit you to say, add => '1 hour', to the current time, to "format"
> the time for a clock that is moving one hour too slow? I agree it is
> rather absurd and silly, but I'm not seeing why it is /more/ silly.
>
> Maybe it would be better if for your understanding you read all of
> these arguments as implicitly suffixed with
> "as_used_in_the_constructor_to_DateTime", so you don't confuse the
> DT::Format::* with something that can or should manipulate the
> supplied DateTime in the call to parse_datetime.
>
> --
> Evan Carroll
> System Lord of the Internets
> http://www.evancarroll.com
>
Reply
On Wed, Dec 16, 2009 at 2:40 AM, Evan Carroll <m...@evancarroll.com> wrote:
> > 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 the
> > module.
>
> I simply /do not/ believe you understand the difference between being
> 1:30 "read-in the context of" America/Chicago, and "converting it with
> date-math" to the timezone of America/Chicago. The constructor
> argument has /nothing at all/ to do with what your wanting (date-math
> convenience).
>
> >> Here is better API idea, why not just make the hash ref to
> >> format_datetime, a huge method wrapper!!!!
> >
> > Taken to the point of absurdity.
>
> But why not? If your goal is simply to provide a convenience wrapper
> that is capable of doing the date-math through DateTime, then why not
> permit you to say, add => '1 hour', to the current time, to "format"
> the time for a clock that is moving one hour too slow? I agree it is
> rather absurd and silly, but I'm not seeing why it is /more/ silly.
>
> Maybe it would be better if for your understanding you read all of
> these arguments as implicitly suffixed with
> "as_used_in_the_constructor_to_DateTime", so you don't confuse the
> DT::Format::* with something that can or should manipulate the
> supplied DateTime in the call to parse_datetime.
>
> --
> Evan Carroll
> System Lord of the Internets
> http://www.evancarroll.com
>
