On Tue, Dec 15, 2009 at 5:01 PM, Evan Carroll <m...@evancarroll.com> wrote:
> On Tue, Dec 15, 2009 at 3:39 PM, Kevin McGrath <kmcgr...@baknet.com>
> 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
> > of that formatter should be able to be based on that time zone.
>
> The problem is DateTime is made to simulate a pipeline
> `Text().asDateTime().asText()` what it provides is the conversion to
> and from a string. The logical way to do what you want is
> `Text().asDateTime().convertToTimezone($tz).asText()`. But, yet you
> seem to be fixated on doing this Text().asDateTime().asText($tz), The
> issue with that is it doesn't really model real world problems or the
> mechanics. Making something as text in a different timezone, would
> require a conversion which isn't really aptly described by a method
> name like "format_datetime", even your code does this
> "$dt->clone->set_time_zone($self->time_zone);".
>
>
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?
In your later example where you 'go on with life', you should:
my $dt = $Strp->parse_datetime($my_string); #Floating
$dt->set_timezone($my_time_zone);
That way you only ever have one Format object. Why would you create a
DateTime::Format::Strptime object for each timezone you want to parse
strings for? Or for that matter why even take a locale?
my $dt = $Strp->parse_datetime($my_string); #Floating
$dt->set_locale($locale);
$dt->set_timezone($my_time_zone);
After all, all I need is a datetime object to 'go on with life' and do all
the datetime modifications myself.
The module however does all these conversions for you automatically and it
doesn't appear to be a problem from the parsing angle.
> The other problem is that you were suggesting overriding TimeZone to
> make it confusingly apply to output patterns in the same explicit way
> that it is currently applied to input patterns. Lets look at your
> provided code:
>
> my $Strp = new DateTime::Format::Strptime(
> pattern => '%T',
> locale => 'en_AU',
> time_zone => 'Australia/Melbourne',
> format_with_time_zone => 1
> );
>
>
Not overriding time_zone, just format_datetime if and only if a option is
set. The attribute 'time_zone' seems pretty generic to me, it's not
'parse_time_zone' or 'time_zone_from_string'. The confusing part is that
it's just named 'time_zone'.
> What should this do on parse_datetime? Read a datetime as if it was
> from Austrailia/Melbourne?
Yup
> And then what on formate_datetime? convert
> it it to Austrailia/Melbourne, which it is already in for the output?
>
>
Be pretty easy to check if the object is already in the desired time_zone
before conversion
> What you would really want is something like this
>
> my $Strp = new DateTime::Format::Strptime(
> pattern => '%T',
> locale => 'en_AU',
> time_zone => 'Australia/Melbourne',
> output_time_zone => 'America/Chicago'
> );
>
>
Actually that would be pretty cool, because I could parse all of my DateTime
strings to UTC and format all my DateTime objects to a desired time_zone
within a single formatter.
my $Strp = new DateTime::Format::Strptime(
pattern => '%m/%d/%Y %T',
locale => 'en_US',
time_zone => 'UTC',
output_time_zone => 'America/Chicago'
);
Even better would be:
my $Strp = new DateTime::Format::Strptime(
pattern => '%m/%d/%Y %T',
locale => 'en_US',
parse_time_zone => 'UTC',
output_time_zone => 'America/Chicago'
);
> But even then? Is this really practical? People that were tasked with
> the same thing you're doing might uselessly create a
> DateTime::Format::Strptime object for each output timezone they
> needed, when all they had to do was call the ->set_time_zone method on
> the $dt object returned from parse_datetime, and then go on with life
> feeding it to format_datetime.
>
>
In a real world application the user settings could easily include more than
just a time_zone
my $Strp = new DateTime::Format::Strptime(
pattern => $user->datetime_pattern,
locale => $user->locale,
time_zone => $user->time_zone,
);
The above is a much more 'real world' application of a formatter. But I do
see your point of using just one formatter for all datetime objects if you
only have one way of displaying dates and or times.
Also, why is it practical to do something like the following for parsing
which you appear to be fine with:
my $Strp = new DateTime::Format::Strptime(
pattern => $user->datetime_pattern,
time_zone => 'America/New_York',
);
my $Strp2 = new DateTime::Format::Strptime(
pattern => $user->datetime_pattern,
time_zone => 'America/Chicago',
);
As I mentioned before in your logic flow this shouldn't happen. It should
return a floating value putting the onus on the user to set the correct
time_zone, etc, so there is truly only one formatter. In that case the
constructor would just be:
my $Strp2 = new DateTime::Format::Strptime(
pattern => $user->datetime_pattern,
);
All other work is done after this.
You make it sound like time_zone and locale shouldn't even be apart of this
module.
-Kevin
--
> Evan Carroll
> System Lord of the Internets
> http://www.evancarroll.com
>
