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
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
On Tue, Dec 15, 2009 at 7:28 AM, Kevin McGrath kmcgr...@baknet.com wrote:
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.
I know traditional convention does not account for this. That is why I was
merely suggesting a 'format_with_time_zone' option you could pass to the new
constructor.
DateTime::Format::Strptime already takes time_zone as a parameter. Why
should you have the set the time zone as an extra step
I like the new option idea Kevin proposes. Seems more straightforward.
Just my 2 cents...
B
-Original Message-
From: Kevin McGrath [mailto:kmcgr...@baknet.com]
Sent: Tuesday, December 15, 2009 2:23 PM
To: Evan Carroll
Cc: datetime@perl.org
Subject: Re: time_zone and
Basically I have a subclass of DateTime::Format::Strptime that takes one
more parameter; a boolean that if true will format the datetime object with
what is returned from time_zone.
This sounds like a bad idea, because you made note that you're doing
this on format_datetime, time_zone by
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',
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
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
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_string); #Floating
Not floating, that is whatever the time_zone you have
On Tue, Dec 15, 2009 at 6:51 PM, Evan Carroll m...@evancarroll.com 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 =
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 jim.mo...@yahoo.com wrote:
How about an entirely new, high-level abstraction
I have discovered a potential DOS attack for all Perl applications which use
DateTime and time zones.
Last July I reported that getting a localized date in the future was very slow.
http://rt.cpan.org/Public/Bug/Display.html?id=47671
$ time perl -wle 'use DateTime; print DateTime-new( year =
On Tue, Dec 15, 2009 at 4:54 PM, Michael G Schwern schw...@pobox.com wrote:
I have discovered a potential DOS attack for all Perl applications which use
DateTime and time zones.
Last July I reported that getting a localized date in the future was very
slow.
On Tue, Dec 15, 2009 at 6:12 PM, Lyle webmas...@cosmicperl.com wrote:
Michael G Schwern wrote:
Clever watchdogs can prevent this from bringing down a server, but I think
we can all agree that a date library should not be the source of DOS
attacks.
Maybe a warning of this in the POD would
On Tue, Dec 15, 2009 at 7:03 PM, Bill Moseley mose...@hank.org wrote:
On Tue, Dec 15, 2009 at 6:12 PM, Lyle webmas...@cosmicperl.com wrote:
Michael G Schwern wrote:
Clever watchdogs can prevent this from bringing down a server, but I think
we can all agree that a date library should not be
But the difference is I'm not really adding functionality, and nothing
is happening under the hood to the DateTime object, just a new value
will be supplied to the DateTime constructor.
I guess I still don't see how:
$Strp-format_datetime( $str, { time_zone = $tz1 } );
On Tue, 15 Dec 2009, Michael G Schwern wrote:
I know efficient 64 bit local time calculations are possible because the
standard C library does it. Its not because its written in C, its because
its using a non-O(n) algorithm.
Fantastic. So I can expect a patch some time soon then?
-dave
On Tue, Dec 15, 2009 at 7:58 PM, J. Shirley jshir...@gmail.com wrote:
My vote goes for no changes, as it is in the POD as a warning and has
existing for a very long time. The better fix is to write better
applications.
Wise words. It's about time all those existing organizations and
On Tue, Dec 15, 2009 at 8:54 PM, Bill Moseley mose...@hank.org wrote:
On Tue, Dec 15, 2009 at 7:58 PM, J. Shirley jshir...@gmail.com wrote:
My vote goes for no changes, as it is in the POD as a warning and has
existing for a very long time. The better fix is to write better
applications.
Applicable snippet:
Do not try to use named time zones (like America/Chicago) with dates
very far in the future (thousands of years). The current
implementation ofDateTime::TimeZone will use a huge amount of memory
calculating all the DST changes from now until the future date. Use
UTC or
On Tue, Dec 15, 2009 at 11:39 PM, Evan Carroll m...@evancarroll.com 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
On Tue, Dec 15, 2009 at 9:21 PM, J. Shirley jshir...@gmail.com wrote:
Perhaps I'm cynical, but in my mind the type of people who write bad
applications not only wouldn't care about potential DateTime DoS
attacks, but they would have many more egregious offenses.
That's true, but you are
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
24 matches
Mail list logo
