any way to download this?

[dinkypumpkin]

On 24 Mar 2011, at 18:33, dinkypumpkin wrote:

> On 24 Mar 2011, at 17:38, Jon Davies wrote:
> 
>> On 24 March 2011 16:57, Nick Ludlam <nick at recoil.org> wrote:
>>> Dinky, is there a more long term fix you can think of for this? I'm sure this isn't the only time that dates will rear their heads, and it would be great to have a solution for the issue.
>> 
>> On what types of system do the dates fail?  I can't reproduce a date
>> problem with perl 5.10.1 on ubuntu 10.04 or windows xp.
> 
> I think it depends on both Perl version and 64/32-bit build settings.
[snip]

I drilled into this a bit more, and I think the cause actually lies inside Time::Local, the home of timegm().  Version 1.18 of the module (installed with OSX Perl 5.10.0 and Strawberry Perl 5.10.0) computes limits inside timegm() using $Config{intsize} (size of C int = 4), while later versions use $Config{ivsize} (architecture size of int = 4 or 8).  Presumably that was an outgrowth of fixing up date handling for 5.11.  Anyway, that's the reason why with a 64-bit Perl on OSX I still hit the limit for 32-bit dates.  It also turns out that the timegm() limit is actually slightly before the nominal limit. 

I think this just confirms my suspicion that whether or not get_iplayer bombs will depend on a combination of OS architecture, Perl version, Perl configuration, and Perl module versions.  There's no point in trying to wrangle with the permutations, though it might be possible to do some runtime checks of Time::Local version and Perl %Config values to determine if a limitation should be enforced.  It might be simpler to just check the Perl version: if < 5.11, enforce the the limit.  Even easier: just hack it like I did and worry about in 26 years.