VMS also "popularized" The microfortnight as a unit of time. In SYSGEN if you set the TIMEPROMPTWAIT value, it was in microfortnights. That would be how long the system would wait at console during a boot if it didn't have a valid time in its system clocks. Presumably your attentive operator would enter one during this interval.

Insurers and financial institutions had to deal with quite a few of their Y2K problems well ahead of the year 2000. Figuring out rates and percentages on a 30 year loan would have you calculating dates after 2000 as far back as 1970, when Unix was still being created.

I wonder how many of these companies started seeing problems back in 2008?

Lots. It wasn't catastrophic at the time -- in most cases. (There were a few!)

I remember when HP was trying to test their DC in Germany, they rolled the computers (and the VMs) up, and then back, but the DC locks, well, locked, and the staff couldn't get in to access the computers to resolve any RT logging info spewing out. Fun times.

Many of the Y2K problems were handled annually, monthly, weekly, daily, hourly, minutely and secondly well in advance of "the deadline".

I cut my teeth on a VAX/VMS system when I was younger and always had a fondness for it. I have an AlphaServer system at home with OpenVMS on it, and occasionally play around with it.

Anyone who's played the more recent Fallout (non MMO) games is familiar with a few commands, interestingly.

Oh! Nice find!

https://fallout.fandom.com/wiki/Terminal_commands

Have to revisit that, was a quarter my age when that came out.

I googled around and it seems OpenVMS does in fact have a 32 bit time_t. Unfortunate given that per the article it seems to use 64 bit quantities in the layer below.

But the article says:

> Given this base date, the 100 nanosecond granularity implemented within OpenVMS and the 63-bit absolute time representation (the sign bit must be clear), ...

It's unfortunate that an article about time isn't itself dated or timestamped!

I found a google groups pseudo-newsgroup comp.os.vms discussion dated 2017 which shows that OpenVMS 8.3 still had 32-bit time_t: https://groups.google.com/forum/#!topic/comp.os.vms/QCms9ZzR...

Pretty sure the posted article is wrong about 63-bit because at the intro it clearly says, "All Versions" yet here we see that as of 8.3 it was still 32-bit. OTOH, in that newsgroup article they show OpenVMS producing a time of year 2106, which is beyond the 32-bit range of the unix epoch. So I'm pretty confused.

> I found a google groups pseudo-newsgroup comp.os.vms discussion dated 2017

Saw that too in my googling, fair warning that several commenters on there seem misinformed. (The code sample at the start is incorrect and some comment rebuttals seem to misunderstand or get it partially correct. In particular some people seem to think time_t is a struct with int components or that sizeof(int) has something to do with time_t.)

> Pretty sure the posted article is wrong about 63-bit because at the intro it clearly says, "All Versions" yet here we see that as of 8.3 it was still 32-bit.

The point is that the kernel doesn't keep the time as time_t. It has a different epoch and unit, and the C runtime needs to convert it to time_t. So the fact that 63 bits (64 if you count signed bit) is used internally says nothing about time_t at the libc layer.

Windows has it similarly. There, the epoch is 1/1/1601 and the unit is 100ns, stored as 64 bits.

> The point is that the kernel doesn't keep the time as time_t.

Does the kernel (linux or VMS) care about absolute calendar time at all? time_t is a strictly userspace construct is it not?

Short answer is yes it does.

One example where the kernel needs to care is that the filesystem maintains the last write time on files. I am sure there are many others.

And if not having the kernel store a time somewhere, where must it come from? Userspace cannot fabricate it from nothing. Even if the kernel used some "relative" thing, where does the base offset come from? However you answer that, keep in mind all processes have to agree, writing it needs to be privileged, it might need to read and write a hardware clock, etc., all problems storing it in the kernel solves.

Also keep in mind that time_t is not a "calendar" construct, it is an integer, and it's not time zone specific. User mode can and does build calendars and time zones on top.

I would hazard a guess that the last POSIX/SuS VAX/VMS were coded against still specified a 32-bit time_t, which would have likely polluted their proprietary userspace. The OpenVMS guys were shooting for compatibility, so it stuck. Legacy is a PITA.