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.
