Welcome to the new Woodmann RCE Messageboards Regroupment
Please be patient while the rest of the site is restored.

To all Members of the old RCE Forums:
In order to log in, it will be necessary to reset your forum login password ("I forgot my password") using the original email address you registered with. You will be sent an email with a link to reset your password for that member account.

The old vBulletin forum was converted to phpBB format, requiring the passwords to be reset. If this is a problem for some because of a forgotten email address, please feel free to re-register with a new username. We are happy to welcome old and new members back to the forums! Thanks.

All new accounts are manually activated before you can post. Any questions can be PM'ed to Kayaker.

2038 issues, the linux 'millenium' bug

Interesting low-level stuff, operating system related issues, packer/vx acrobatics, drivers and non-newbie programming in general, including win32 assembly and whatever else.
Junior Member
Posts: 1
Joined: Sat Mar 29, 2014 8:56 pm

2038 issues, the linux 'millenium' bug

Post by studleylee »

I have older sw that I use that I would like to keep alive through 2038( if I'm still functioning :-). Flexlm ( from 2004 ) suffered(s?)
from not letting permanent licensing past 2038. Linux and sw that had origins related to linux code have a rollover issues
in the year 2038. google "2038 issue" for more background.

I've tested this by moving the clock ahead and sure enough the licensing fails. I can create files that date past 2038, but the program still locks up
after 2038, so it's in the date gathering code.

It's more of an academic exercise, but I'm thinking of wrapping it's getdate or whatever
and making a workaround. Has anyone run into this? I've hear of the 'touching files' to find what is collected for
establishing that the time has not been setback etc. Maybe that's an avenue?
Thanks for thought on this.