[Info-vax] 2038 32-bit time_t overflow, was: Re: DCL Output Parsing, Compatibility, and Terrible User Interfaces

[Bill Gunshannon]

On 12/2/18 7:21 AM, Johnny Billquist wrote:
> On 2018-11-28 21:19, Bill Gunshannon wrote:
>> On 11/28/18 5:19 AM, Johnny Billquist wrote:
>>> On 2018-11-26 21:10, Dave Froble wrote:
>>>> I thought 2038 was a C issue, not an OS issue.  Did I misunderstand?
>>>
>>> Technically it can't be a C issue, because C itself have no clue 
>>> about time. But it's a potential issue with the C standard library.
>>>
>>> It might be that the latest C standard also includes the standard C 
>>> library (I have a vague memory that it is), but I think it just says 
>>> time_t, without saying how that type actually looks like.
>>>
>>> Unix internally uses that same format, so for Unix it is a real issue 
>>> with or without C. So it's definitely an OS issue.
>>>
>>> And the format is basically just the concept of seconds since the 
>>> start of the epoch, which is defined as Jan 1, 1970.
>>> And if you use that, and the value is stored in a signed 32 bit 
>>> integer, then you'll roll over in 2038.
>>>
>>> So any program that uses this format, with such a data type, will get 
>>> into trouble. No matter which OS it runs on, and no matter which 
>>> language is used.
>>>
>>> And any OS that uses this format, with such a data type, will get 
>>> into trouble, no matter what application is running, written in any 
>>> language.
>>>
>>> VMS obviously do not have a problem with the latter scenario, but can 
>>> have trouble with the former.
>>>
>>> (And PDP-11 C under RSX will definitely hit this problem as well, 
>>> since time_t is a signed 32-bit integer there, even though internal 
>>> time in RSX won't flip over and die until the year 34668 at the 
>>> earliest.)
>>>
>>> And just to be clear, most Unixes have long since addressed this by 
>>> extending time_t to 64 bits. But anyone with an old, legacy version 
>>> of Unix will surely hit fun times in 2038 as well.
>>>
>> So you mean my Ultrix-32 systems will enter the same twilight zone
>> as my RSTS systems. :-)
> 
> I haven't looked at Ultrix-32, but if you say so...

It's pretty much vanilla SYSV with a few BSD accretions. Got to have
the problem.  And I have never seen source made available.  Plus, it
is not covered by the license that freed older Unix versions so not
likely to be able to fix it.  Unless someone decided to try to do it
with ADB.  Good luck with that!!

> 
>> I left Ultrix-11 out of this as I have the source so I can fix it
>> when the time comes.  :-)
> 
> Ultrix-11 seems like a high probability of having the problem. Time to 
> start fixing. :-)

No doubt, but I was able to Y2K it, so anything is possible.  Maybe
even make it run on my VAX instead of Ultrix-32.  After all, Unix is
Unix.

Hmmmm...  Wonder if anyone is looking at fixing BSD 2.11?

bill