Y2k38 support

[Arantor]

Everyone thinks the Y2K bug went off with minimal hitches - the reality is that best part of 20 years of planning and execution were carried out.

With that in mind, I propose getting in Y2K38 support now as a gesture for long-term support, and ensuring that there is an upgrade path sooner rather than later.

I've been using SMF for 16 years, I'd like to see it survive another 16.

I have no strong views on whether this is done by way of using bigints or using datetimes, but either way I'm getting it on the list now so it can be considered.

[vbgamer45]

I think about it too at times. I been joking telling people that's when I will retire before that happens.

[Sesquipedalian]

If we drop support for 32-bit builds of PHP—and by 2038, anyone using 32-bit anything will deserve every problem they get—then I believe the only change we will still need to make is ensuring that all relevant database columns can handle larger integers.

Within our code we should already be fine, as long as PHP is 64-bit. PHP 8.1 deprecated strptime() and strftime(), which relied on system libraries rather than PHP's internal date handling and were therefore potentially vulnerable to Y2K38. We never used the former, and we've replaced all calls to the latter with a compatibility function that internally uses DateTime. Since the date functions in 64-bit PHP are unaffected by Y2K38, we should be good to go.

Of course, if we decided to keep support for 32-bit PHP, everything goes out the window. We would need to remove all use of Unix timestamps absolutely everywhere. That'd be a horrendous amount of pain in order to maintain support for what will by then be ancient technology, and trying to do so would be just plain stupid.

[live627]

I thought PHP uses time_t and thus we only need to resize database columns.

[Arantor]

Yes but when the numbers come out of the database and before they get to DateTime...

Though most of the time there, they are strings, by virtue of MySQLi. Which leaves you with any and all calls to time().

I wasn't too fussed at this stage with the actual mechanics, more getting it out there so it can be planned in on your roadmap. (Something I spent a long time butting heads with Albert yesterday, none of my Feature Requests are super detailed or with implementation notes because it's too early for that.)

[Aleksi "Lex" Kilpinen]

Just want to leave a quick note here, that I like seeing this open brainstorming that's going on.