[CRM114]

Hey pals, I am curious I was just reading an article about all the crazy issues going on with y2k patches that broke this year with the 2020 rollover. [article here]. I am not sure why I did not think about the 2038 problem as it relates to my pretty little collection of SGI machines- but I am thinking about it now.

I am not at home and will have to fire some machines up and roll their clocks to see what breaks. Is there anything we should consider? With the OS being closed source if there is anything low level broken I guess we just wont be able to have accurate clocks anymore? Not sure what all this could break from a software and services standpoint. 

Thoughts? 

[Year 2038 Wiki Page with nice animation here]

[Raion]

IRIX is affected by the Y2038 issue AFAIK. There's no good solution to fixing legacy software that stores the time value:

SSL won't work
Old browsers and services won't work over SSL
Any commercial software using date codes will fail somehow
Kerberos, SSH and other services may be affected

There's no way to fix this issue other than if we rebuild the OS from FOSS parts, and either change the 32-bit signed value to unsigned (Will affect anything doing dating before 1970) or to a 64-bit signed. Even incrementing it to an odd value like 48 bits won't fix anything more effectively.

[miod]

IRIX is affected by the Y2038 issue AFAIK.

Indeed, all IRIX versions use a 32-bit signed integer type for time_t, and will rollover in 2038.

[Raion]

Well, that kind of adds motivation for a FOSS IRIX clone then huh.

[sunray]

Hmm, I have read somewhere that IRIX64 is not affected by this issue.

[jan-jaap]

Hmm, I have read somewhere that IRIX64 is not affected by this issue.

Wrong

Code:

janjaap@speedo:~$ uname -a

IRIX64 speedo 6.5 07202013 IP35

Code:

#include <stdio.h>
#include <time.h>

int main(void)
{
        printf("sizeof(time_t) = %ld\n", sizeof(time_t));
        return 0;
}

32 bit

Code:

janjaap@speedo:~$ cc -o hello hello.c
janjaap@speedo:~$ ./hello
sizeof(time_t) = 4

64bit

Code:

janjaap@speedo:~$ cc -64 -o hello hello.c
janjaap@speedo:~$ ./hello
sizeof(time_t) = 4

Well, that kind of adds motivation for a FOSS IRIX clone then huh.

The problem is in the IRIX C library. As long as you don't use the time functions from the C library you're fine. You could for example relink your applications against a small static library with time functions based on a 64bit time_t. But first we'll have to see how many IRIX systems are still running in 2038.

FWIW: IRIX 4 isn't even Y2K compliant and that doesn't stop me from using on some of my systems.

[sunray]

Hmm, I have read somewhere that IRIX64 is not affected by this issue.

Wrong

Code:

janjaap@speedo:~$ uname -a

IRIX64 speedo 6.5 07202013 IP35

Code:

#include <stdio.h>
#include <time.h>

int main(void)
{
        printf("sizeof(time_t) = %ld\n", sizeof(time_t));
        return 0;
}

32 bit

Code:

janjaap@speedo:~$ cc -o hello hello.c
janjaap@speedo:~$ ./hello
sizeof(time_t) = 4

64bit

Code:

janjaap@speedo:~$ cc -64 -o hello hello.c
janjaap@speedo:~$ ./hello
sizeof(time_t) = 4

Well, that kind of adds motivation for a FOSS IRIX clone then huh.

The problem is in the IRIX C library. As long as you don't use the time functions from the C library you're fine. You could for example relink your applications against a small static library with time functions based on a 64bit time_t. But first we'll have to see how many IRIX systems are still running in 2038.

FWIW: IRIX 4 isn't even Y2K compliant and that doesn't stop me from using on some of my systems.

Yepp, that speaks for itself, its a pity but it's a few years still to run for the machines and us

[Raion]

All it requires is for us to come together as a community for a FOSS version of IRIX from scratch.