any way to download this?

dinkypumpkin dinkypumpkin at gmail.com
Thu Mar 24 14:30:15 EDT 2011


On 24 Mar 2011, at 16:57, Nick Ludlam wrote:

>> [snip]
>> If any maintainers read this, I should point out that there seems to be a genuine bug in bounds checking of dates.  Only the year was being changed to reflect the limit of 32-bit unix time, but unix time runs on out 2038-01-19.  In this case, the expiry date in the metadata was 2041-03-17 23:59:00, which was changed to 2038-03-17 23:59:00, so the script bombed because the date was still invalid.  I can post in a separate patch if you prefer.
> 
> 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.

I'm not entirely sure.  I hope the proper Perl coders here can provide a definitive answer.  I think the problem manifests itself if either: a) Perl version is too old; b) Perl build is 32-bit.  Perl 5.11+ can handle dates > 32 bits on 32-bit systems, but I need to verify that with get_iplayer.  Forcing a new Perl version might be simple enough for Windows get_iplayer (update the installer - Strawberry Perl has 5.12 version), but OSX/Linux users would be left to their own devices and the vagaries of their particular distros.  I'll do a bit more investigating and post again.

To be honest, a hack something like mine is probably good enough until the default version of Perl on OSX and [insert essential Linux distros here] advances beyond 5.10.  If that hasn't happened by 2037, something has gone desperately wrong.


More information about the get_iplayer mailing list