Strange that they wouldn't use NULL to mean never expires, rather than setting a timestamp arbitrarily far into the future.

I'm sure "normal people" would get a bit confused by that... It's nothing that an if statement couldn't fix though...

I think they've got something like that - I'm sure I've seen programmes with "available for more than a year" which I took as a message that a developer had put in to cover a case where there is no explicit expiry date

My guess further down the thread is that they were setting an unsigned int to -1. On 32-bit that would set it to 2038.

And because (unint32's -1 != unint64's -1), it wouldn't show the "never expires" text.

The available until date is set to 18th of January 2038. So someone, for whatever reason, deliberately set it to one day earlier than 0x7FFFFFFF, either at 00:00:00, 03:14:07, or 23:59:59 (pick your poison).

Maybe the new guy wasn't aware of the value to get it to say "for more than a year", which might be -1.

I wonder if NULL actually does mean never expires, and right now one BBC BOFH is showing this article to another BBC BOFH and demanding they cough up the £20? I mean - a bet's a bet, after all.

The Tories are on this and come 2038 nobody will have to worry about accessing anything biased on the BBC.

Or more possibly, anything what so ever on the BBC......

@TheProf

That does depend on the tores getting elected next time but the BBC seems more than a little worried that without the TV tax they wont be around. Not surprised they are worried based on their content.

I'm glad you eventually get round to pointing out it's not a uniquely unix problem. Most (all?) implementations of C uses the "POSIX epoch" of Jan 1st 1970 so any C compiler with a 32 bit signed int for time_t is in the shit. Although I've just checked the spec and neither the width nor the epoch are mandated in modern C standard. (I've not looked backwards to see if it ever was.)

The real problem is not application but filesystems and file formats which have used a 32 bit signed time_t in the format. That's more of a unix problem.

Anyway, it looks like this will pay for my retirement!

Officially you should use the typedef name "time_t", but historically the calls and documents used "long" in old Unix, and many programmers have lazily continued using it for time without the typedef name. On 32-bit Linux and most other 32-bit systems, "long" is 32-bits. On 64-bit Linux, "long" grew to 64-bits, but 64-bit Windows still keeps it at 32-bits for backward-compatibility. So a Windows program that at some point uses bare "long" for time will have trouble, but one on Linux will not!

VMS (since 1977) has stored time as 100ns clock ticks since 17 November 1858 (the start of [1]the Reduced Julian Day (an astronomical timescale, the "reduced" variant was introduced by the Smithsonian Astrophysical Observatory in 1957 to record the orbit of Sputnik). It will run out of bits in the year 31,086.

[1] https://en.wikipedia.org/wiki/Julian_day

...and about 29,000 years from now, someone will have discovered an ancient calculation machine and will have figured out how it worked. And they will see that its clock stops in the year 31,086. And some of them will start a cult that believes the end is near for an ancient civilisation allowed their calender to run until then...

What’s the clock used on VGER?

VMS got most things right.

There is, though, a well-known bug filed against VMS for a related issue. The standard message display only permits 4-digit years, so even if the clock is fine until 31,086 there will be a display error when it ticks over on Dec 31st 9999. Last time I saw that bug in the DEC tracking system it was in an 'accepted' state, with a note that it will be fixed "in a future major architecture". Sadly unlikely now...

>with a snapshot that implies Old Auntie might be using a 32-bit Linux in iPlayer

This would be among the least likely explanations, given this is a value encoded in a database somewhere. Most likely on a technical basis is someone is using MAXINT for "never expires", which is always going to land at that epoch however big your epoch may be allowed to grow.

Or perhaps someone in the iPlayer team has a mischievous streak and set the displayed maximum there deliberately as a nod to their fellow technologists.

Given the iPlayer volume slider goes to 11, I know which of the two I'd prefer to be true.

Ah,

My guess based on your post, they previously used MAX_INT. They updated to 64-bit and 2038 no longer matches MAX_INT.

Close. The point is that MAX_INT is almost always going to be 2,147,483,647, regardless of whether you're using C/C++ on a 32 or 64bit linux, writing some enterprise glue code in Java or storing that value into an Integer field in MySQL.

2,147,483,647 always lands you on that magic moment in 2038, regardless of whether your epoch is represented as a 32 or 64 bit number. The real question is what your system does with epoch 2,147,483,648, not what it does with the predecessor.

Well, if not MAX_INT, then -1 on an unsigned int.

If that int became 64-bit it would no longer match the date in 2038.

MAX_INT is going to be the maximum value for the integer size of the machine, whether than be 32, 64, 128, or some bizarre number of bits, not the maximum value of a 32-bit integer ala older boxes or Java.

Yes. I learnt to program on a machine with MAX_INT = 8388607(*)

(*) Well, it would have been if there had been a C compiler for it. Dennis Ritchie had only just started inventing C back then.

Not compliant these days of course, needs a number

Erm... "Palin's Round The World In 80 Days" on BBC4, or "Round The World In 80 Days" with David Tennant on BBC1?

(not sure why they are broadcasting both series at the same time!)

Cisco have got round the y2038 problem by redefining 'day zero' for the RTC... some default to 1/1/2010, others to 1/1/2013, when the NVRAM battery goes flat (depending on IOS version)

Or "Around the world in 80 gardens", which is also on. Almost sat down to watch that with the kids by mistake the other day, which I imagine would have gone down like a bucket of cold sick.

Probably someone realised that the plot & characters of the Tennant-inhabited series was entirely unlike the actual book -- and so that someone then thought the Palin one might serve as a more accurate representation :-)

Indeed, I re-read the Verne original very recently -- in fact, just after thinking "I don't remember any of that" during Tennant Ep.1).

Arguably (IMO), a fair fraction of the book is not necessarily well matched to the demands of modern TV, so a significant degree of "updating" was probably to be expected. It is a shame, though, that so little of the original was allowed to survive, and even that is mutilated. Mind you, perhaps Eps 7&8, which I haven't seen yet, are less off-piste?

Have Unisys now totally expunged this issue from their OS1100/2200 systems?

Hell yes I feel old. I helped erect Stonehenge Version 0.75Alpha as a test run before we erected the full V1.0. Due to budget overruns & manglement cockups, I'm still waiting for the damned thing to finish POST.

Wake me when it beeps...

Didn't it get reset during the last total eclipse?