What QUARTUS Release fixes Year 2038 bug?

[MatthewSteger]

We are using Cyclone IV chips (one is EP4CE30F23) with Quartus 11.1sp2 Build 259 and this NIOSII "system" *HAS* the Year 2038 bug because "time_t" is defined as a SIGNED 32-bit integer.

This is a PROBLEM, see https://en.wikipedia.org/wiki/Year_2038_problem

What version of QUARTUS (including GCC and RE-definition of "time_t") can I upgrade to in order to ensure dates after 2038 will work.

NOTE: I do *NOT* Care about dates PRIOR to 1970 so I am OK (and would actually PREFER) a simple change of "time_t" to UNSIGNED 32-bit Integer which would give us until 2106 (per link above)...our products won't last that long, but they certainly will be around past 2038.

We use SmartCards in our system and they generally have a 10 year Expiration Date so RIGHT NOW that is MID 2031...so we are getting CLOSE to having issues (cards will start expiring PRIOR to 1970 and thus would be EXPIRED).

[MatthewSteger]

We are using Cyclone IV chips (one is EP4CE30F23) with Quartus 11.1sp2 Build 259 and this NIOSII "system" *HAS* the Year 2038 bug because "time_t" is defined as a SIGNED 32-bit integer.

This is a PROBLEM, see https://en.wikipedia.org/wiki/Year_2038_problem

What version of QUARTUS (including GCC and RE-definition of "time_t") can I upgrade to in order to ensure dates after 2038 will work.

NOTE: I do *NOT* Care about dates PRIOR to 1970 so I am OK (and would actually PREFER) a simple change of "time_t" to UNSIGNED 32-bit Integer which would give us until 2106 (per link above)...our products won't last that long, but they certainly will be around past 2038.

We use SmartCards in our system and they generally have a 10 year Expiration Date so RIGHT NOW that is MID 2031...so we are getting CLOSE to having issues (cards will start expiring PRIOR to 1970 and thus would be EXPIRED).

[BoonBengT_Intel]

Hi @MatthewSteger,

Thank you for posting in Intel community forum, hope all is well and apologies for the delayed in response.
Per my understanding the time_t function is a arithmetic type from C++ and it depends on the systems it is used, it can be 32-bit or 64-bit.
Hence would recommend to use use the _time64 to solve the Jan 18'2038 issues. (more details can be refer here)

As for the quartus version that are supporting 64-bit, after some investigation would recommend to try on the Quartus 19.2 pro version and above that comes with gcc 8.3.1 above, which should support the64-bit build.
Hope that clarify your doubts.

Best Wishes
BB

[MatthewSteger]

I found out that GCC is *NOT* the one controlling time_t/time64_t it is done by the "C Library" which I am sure in this case is the ALTERA (now IBM) C Library (per below)...

So AGAIN, what version of QUARTUS is needed to (ideally) have a 32-bit UNSIGNED Time or have a 64-bit SIGNED Time in the QUARTUS C Libarary?   QUARTUS 11.1sp2 has "time_t" in:  c:\altera\11.1sp2\nios2eds\bin\gnu\H-i686-mingw32\nios2-elf\include\sys\types.h and there is no "time64_t" defined in that file!

From GCC:

On Wed, 7 Jul 2021, 21:10 Steger, Matthew via Gcc-help, <gcc-help@gcc.gnu.org> wrote:

What version (exactly) of GCC added the "time64_t" and all TIME Related functions (including Printing formats) allowed 64-bit time (to FIX the Year 2038 issue with "time_t")

Those functions are not part of GCC. They are provided by the C library, not GCC.

If you are using Linux, your C library is probably glibc. It is a completely separate project from GCC with its own releases. 

Also did *ANY* version of GCC support 32-bit UNSIGNED time (good until 2106) including all TIME Related fucntions (and Printing formats)?

GCC supports whatever the C library does.