Zefram wrote:
Michael G Schwern wrote:
A) Have DT::TZ be a wrapper around DT::TZ::Tzfile
B) Have DT::TZ ship with (or download) v2 Olson data
I'd do this in a finer-grained way. One module encapsulating the
Olson tzfiles, with no logic for interpreting them; this can be used
independently of
Zefram wrote:
These issues affect about ten zones in the current Olson database
(depending on how you count them). In principle you'd get better results
by using the DT:TZ approach and just implementing it in a less dippy way.
But the difference in results is not very much, and it's probably
Michael G Schwern wrote:
A) Have DT::TZ be a wrapper around DT::TZ::Tzfile
B) Have DT::TZ ship with (or download) v2 Olson data
I'd do this in a finer-grained way. One module encapsulating the
Olson tzfiles, with no logic for interpreting them; this can be used
independently of DT:TZ:Tzfile, and
Zefram wrote:
J. Shirley wrote:
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.
Michael G Schwern wrote:
That looks like a great place to start. If it matches the DT::TZ
interface, and shipped a default time zone database, could DT::TZ simply
be replaced with it?
Almost. In principle, the DT:TZ way of working handles far future dates
slightly better.
DT:TZ:Tzfile can
On Thu, 17 Dec 2009, Zefram wrote:
Almost. In principle, the DT:TZ way of working handles far future dates
slightly better.
I'd actually say this doesn't matter. Look at how often time zone
definitions change. Looking at America/Chicago, I see changes in 1974,
1975, 1976, 1987, and 2007.
Dave Rolsky wrote:
I don't think you need auto-downloads. People download a new DT::TZ when
I release one, or they don't. No one's complained about that.
It'll only rarely bite people. That doesn't make it OK. But that's an
orthogonal discussion that I don't want to stray into here.
The real
I am, quite frankly, appalled at the response I've gotten to this report.
No, this is not something the user should be guarding against. No,
documenting it does not make it go away. No, you shouldn't put an arbitrary
upper bound in. No, I should not have been using UTC. That is all
Schwern++.
On Wed, Dec 16, 2009 at 4:16 PM, Michael G Schwern schw...@pobox.com wrote:
I am, quite frankly, appalled at the response I've gotten to this report.
No, this is not something the user should be guarding against. No,
documenting it does not make it go away. No, you shouldn't put
On Wed, Dec 16, 2009 at 4:16 PM, Michael G Schwern schw...@pobox.com wrote:
I am, quite frankly, appalled at the response I've gotten to this report.
No, this is not something the user should be guarding against. No,
documenting it does not make it go away. No, you shouldn't put an arbitrary
On Wed, 16 Dec 2009, Michael G Schwern wrote:
Give me something to work with here. Some insight into what and why DateTime
is doing what its doing. Is there a reason that DST info has to be generated
linearly? Would it be difficult to hold off on generating time zone info
until its needed?
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
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 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
20 matches
Mail list logo
