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 an arbitrary > upper bound in. No, I should not have been using UTC. That is all > accepting low-quality. We don't do that in Perl. > > This isn't just an annoyance, its a wide spread security hole triggered by > totally innocent use. Its like finding out my doorbell will cause my house > to explode if somebody buzzes too long. I do not want to program in an > environment where the assumption is that everything is dangerous. This > isn't even a problem one should imagine encountering. > > The reaction I was expecting was more along the lines of "oh fuck, that's > really bad, let's figure out how to fix this". Yes, its ok to report a > problem without a ready solution. Instead, I'm told its documented and to > cough up a patch. > > This is not a simple problem to solve. I'm not even sure what the efficient > DST algorithm is, though I'm looking for it. I've looked into the > DateTime::TimeZone code before and this is not going to be a simple patch. > I'm willing to try and fix it, but not if the DateTime folks, the folks who > know the code, are reacting with something between lethargy and hostility. > It going to be hard enough without dragging everyone along. > > 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? Are there instructions somewhere for dealing > with the Olsen database? SOME sort of discussion about how to solve the > problem rather than the ways to paper over it. >
