Why is Wednesday, November 17, 1858 the base time for OpenVMS?
slac.stanford.edu
slac.stanford.edu
In 1998, a programmer who had been working on Y2K fixes started to get anxious because he couldn't believe how pervasive the problem was. He switched from company to company trying to get away from it, but everywhere he went he became regarded as the Y2K expert and immediately became the team lead for that company's Y2K contingencies. He finally had a nervous breakdown, quit his job, and decided he wanted to be knocked unconscious when the Y2K actually came about.
A month before Y2K he was put into an artificial coma and cooled down to a near cryogenic easily sustained long term life support.
Unfortunately the life support notification system had a Y2K bug, and no one revived him for 8000 years.
Finally he was found and revived. He woke up, and saw himself surrounded by lots of glass, light, stainless steel, and tall beautiful people in white robes. He asked if he was in Heaven.
They replied, "No, this is Chicago. Actually but it's a lot like Heaven to someone like you."
"Someone like me?"
"You are from the 20th century. Many of the problems that existed in your lifetime have been solved for thousands of years. There is no hunger and no disease. There is no scarcity, or strife between races and creeds."
"What year is it now?"
"Yeah, about that - it's the year 9,998. You see, the year 10,000 is coming up, and we understand you know something called COBOL?"
[1] https://www.reddit.com/r/ProgrammerHumor/comments/3aakb8/the...?
> Note that the OpenVMS time display and manipulation routines allow for only 4 digits in the 'YEAR' field. We expect this to be corrected in a future release of OpenVMS sometime prior to 31-DEC-9999.
Mind you, presumably, some civilizations in our universe will go on beyond that. Referencing this† chart, silicon-based life (e.g. maybe even us humans, if uploaded into computers) might be able to survive about half-way into "the Degenerate Era", before the material substrate we run on just radiates away through proton decay. Representing the last second life could exist would require a continuum of 4e32 seconds, or 108 bits.
† https://en.wikipedia.org/wiki/Graphical_timeline_from_Big_Ba...
And also keep in mind, computers (including any silicon-based life-forms) think much faster, and so are in want of much more fine-grained measurements than our unit of "seconds" to place events on their own timelines. We already use nanosecond timestamps for our computer-system-internal log events (which would add a 30-bit fractional part to our 108-bit timestamp, to create a combined 138-bit fixed-point representation.)
But let's be "safe." We don't know how fine-grained we'll need to get! We might want to record data about the first events of our universe, for example. I would think that a "really ultimate", future-proof, archival format for time record-keeping, would probably be denominated in Planck time units.
Interestingly, counting in Planck time units instead of nanoseconds, "only" requires 144 bits for the fractional part!
108 + 144 = 252. Or, rounding up, 256. We could represent any instant of time we could ever care about, in fixed-point encoding††, in a 256-bit word.
†† (It wouldn't really be fixed-point encoding. It'd just be an integer number of Planck time units since the Big Bang. But you can right-shift by 144 to get something close to a count of seconds, which is useful.)
Finally: you still want more? Any time between the creation and heat death of the universe, even though nothing will be around to experience it? Well, that'd be 333 bits worth of seconds. 333 + 144 = 477, which would fit a 512-bit machine word.
One could assume, then, that any Matrix-like universe simulation substrate will have a 512-bit Time Stamp Counter register.
...presuming, that is, that it was built to simulate a universe like our own, and not one that has finer-grained Planck units or which goes on for longer. :)
----
Does all of this have any use? Maybe! If we could figure out precisely what time it is in some objective sense—how many Planck time units have passed here in our reference frame since the creation of the universe—that might be a useful "handshake format" to describe "when" something happened to aliens, when building things like Voyager's Golden Record. (After all, we can teach them about our calendar, but how do we describe+transmit when our calendar began in a way they can measure against in their reference frame, in order to know how to do the math to translate dates back and forth?)
Maybe, though you can bet they don't have to deal with leap years and seconds. Let alone have to adjust the clocks as an earthquake slightly changed the speed of the rotation ever so slightly.
Makes you wonder what they would use as a reference point of time and what units of measure. Pulsars are great, but on the scale of the universe, maybe not that great.
Would be pretty hard on a human timeline though.
That's not actually true. Assuming there's a distinguished "initial" event [the big bang], and your universe does not contain any closed timelike curves [citation needed], you can define a Longest Proper Time from the initial event to any other event as the (obviously) longest proper time that any object or test particle could experience along a (timelike) path from the initial event to the later event.
Simultaneous events have equal LPTs and are always spacelike-separated (if there was a timelike path from A to B then B.lpt (>)= A.lpt + len(path) > A.lpt, so B.lpt!=A.lpt and they aren't actually simultaneous).
After all, we can teach them about our calendar, but how do we describe+transmit when our calendar began in a way they can measure against in their reference frame, in order to know how to do the math to translate dates back and forth?
Is this in reference to something? Did some Y2K patches partially consist of putting Node.js-based gateways in front of mainframes to translate dates back and forth?
All hail CICS Gateway!!!
> The Long Now Foundation was established in 01996 to foster long-term thinking and responsibility in the framework of the next 10,000 years.
It's reminiscent of an MLM page, and MLMs are arguably (hell, demonstrably) cult-like.
Mainly, the "graying old man deep in thought surrounded by beams of blue light" really sets it off though.
I say that with total respect for said movements, but I see why cynical analysis would say cult-like. And there are a few people and groups in similar categories that are cult-like.
While they do have some active projects, like the 10K-Year Clock, it's mostly just a series of monthly-ish talks with a variety of ecologists, engineers, etc., themed around long-term thinking. It's all quite grounded.
I'd suggest others working on OpenVMS check their C compilers before forgetting about the 2038 bug.
It's fun when OpenVMS shows up here! Any other younglings fiddling with it?
https://fallout.fandom.com/wiki/Terminal_commands
Have to revisit that, was a quarter my age when that came out.
> 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.
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.
Does the kernel (linux or VMS) care about absolute calendar time at all? time_t is a strictly userspace construct is it not?
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 wonder how many of these companies started seeing problems back in 2008?
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".
https://docs.microsoft.com/en-us/cpp/atl-mfc-shared/date-typ...
Most people haven’t seen a VAX. I saw them at my university and they were used for various administrative tasks and recordkeeping, but I never used them. I don’t know if they’re still there. The university only had a couple people who knew how to use them.
Generally you will see them hang around, powered on, for long periods of time running some software which has been working for years. You don’t mess with them because they work fine, and messing with a working system will more likely break it than anything else. Every once in a while, you’ll see a job posting for people with VMS experience but it’s tough, because everyone with VMS experience is retired.
See: https://news.ycombinator.com/item?id=20209869
Another company I worked at recently had a VAX, but it was part of the company’s museum!
There's one for $650 now that says it's fully working and comes with a licensed copy of VAX/VMS. There are also a few in the $150-200 range but I don't know if they have an OS on them or not.
http://toyvax.glendale.ca.us/~vance/vaxbar.html
A VAX 11/780, where the Boot switch operates a blender. And the guy doesn't even drink!
At one point, I personally acquired both a MicroVAX and an Alphastation and installed VMS on both. I found it a very boring system, in that it seemed like something you'd configure for a task and it would just do that task forever--I doubt the sysadmins at my school spent a lot of time maintaining the VMS cluster, but it kept on ticking for years!
There was enough interest in VMS such that HP spun off development to a startup near the old DEC HQ outside Boston, who are also working on the port to modern x86-64 hw.
Ah, apparently first boot on x86 has occured:
You can imagine the resistance to shutting down a manufacturing line that's been running fine for decades simply because the hardware is old. A lot of expense goes into getting everything cleared with the FDA, so it's not a trivial matter to replace hardware and software.
Not exactly:
Modern PCs cannot even drive a parallel port with the correct timing. PDP/VAX CPU, RAM, and storage are emulated, but Q-Bus and Unibus interfacing needs to be done with custom hardware.
https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...
> The three cycles are 15, 19, and 28 years long.
Looks like 28 years is how often the calendar repeats, using their count of leap years. The other two seem to be tax and census related?
What an odd way to run a calendar. Every 7,980 years the tax man and the census man will both arrive on the same Monday? Gosh I hope I still remember the next time that happens. No actually I don't. Being alive for 8000 years sounds like torture.
https://en.wikipedia.org/wiki/Julian_day
indication cycle seems to be like a Roman Egypt property tax assessment cycle, used to date medieval documents throughout Europe. I guess Joseph Scaliger must have been looking for notes about astronomical events in archival documents, and wanted to get them all on a consistent calendar.