News:

Want to get involved in developing SMF, then why not lend a hand on our github!

Main Menu

Y2k38 support

Started by Arantor, April 23, 2022, 04:48:01 PM

Previous topic - Next topic

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.
No good deed goes unpunished / All helpful urges should be circumvented

I have something to say: it's better to burn out than to fade away. There can be only one.

vbgamer45

I think about it too at times. I been joking telling people that's when I will retire before that happens.
Community Suite for SMF - Take your forum to the next level built for SMF, Gallery,Store,Classifieds,Downloads,more!

SMFHacks.com -  Paid Modifications for SMF

Mods:
EzPortal - Portal System for SMF
SMF Gallery Pro
SMF Store SMF Classifieds Ad Seller Pro

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.
Slava Ukraini!
Heroiam slava!

I promise you nothing.

Sesqu... Sesqui... what?
Sesquipedalian, the best word in the English language.

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.)
No good deed goes unpunished / All helpful urges should be circumvented

I have something to say: it's better to burn out than to fade away. There can be only one.

Aleksi "Lex" Kilpinen

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


"Before you allow people access to your forum, especially in an administrative position, you must be aware that that person can seriously damage your forum. Therefore, you should only allow people that you trust, implicitly, to have such access." -Douglas

How you can help SMF

Advertisement: