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