
Why is Wednesday, November 17, 1858 the base time for OpenVMS? - kristianp
https://www.slac.stanford.edu/~rkj/crazytime.txt
======
technofiend
As found here [1] but variations are all over the net.

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...](https://www.reddit.com/r/ProgrammerHumor/comments/3aakb8/the_tale_of_a_y2k_programmer_from_the_1900s/)?

~~~
microcolonel
The saddest Demolition Man ripoff ever.

------
pintxo
Worth a read:

> 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.

~~~
dylan604
They have just enough time to schedule meetings to discuss it, code it, review
it, then deploy it. Except they'll discover on 15-DEC-9998 that there's a
critical bug, and it'll be known as Y10K. All of the original developers will
have been long gone, so there's no way of getting them involved. An entire new
development environment will be created so they can run a client based
language as a server to handle the new date format

~~~
derefr
> An entire new development environment will be created so they can run a
> client based language as a server to handle the new date format

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?

~~~
m4rtink
I'm pretty sure there was no Node.js in 1999/2000.

~~~
wahern
Not literally, but Netscape released server-side JavaScript a few months after
adding it to Navigator: [https://en.wikipedia.org/wiki/JavaScript#Server-
side_JavaScr...](https://en.wikipedia.org/wiki/JavaScript#Server-
side_JavaScript)

------
tapland
> OpenVMS should have no trouble with time until: 31-JUL-31086 02:48:05.47.

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?

~~~
asveikau
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.

~~~
jiveturkey
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...](https://groups.google.com/forum/#!topic/comp.os.vms/QCms9ZzRSKU)

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.

~~~
asveikau
> 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.

~~~
jiveturkey
> 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?

~~~
asveikau
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.

------
ape4
Windows uses January 1, 1601.

[https://en.wikipedia.org/wiki/System_time](https://en.wikipedia.org/wiki/System_time)

~~~
buckminster
This ever-so-slightly simplifies the calculations. The pattern of dates has a
period of 400 years. Your first day of year calculation can ignore the year
divisible by 400 leap year rule if you start in the year after.

~~~
dmurray
If you never need to represent dates after 2001, sure.

~~~
buckminster
The calculation for 1/1/2001 is the same as the calculation for 1/1/1601 plus
the number of days in 400 years. So it doesn't have to take into account the
special case of February 2000. (Other than in the number of days in 400 years,
but that's a constant.) I've written the code. It's a tiny bit simpler.

------
smabie
A little offtopic. But what kind of commercial use to VMS have at the moment.
I know there’s a lot of big iron IBM systems around, but haven’t heard much
about VMS (nor have I ever used it). What hardware does it run on? Who is
using it? And for what purpose?

~~~
klodolph
It runs on VAX, Alpha, _and_ Itanium! Woo!

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](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!

~~~
amyjess
Every once in a while, I go on eBay, search for VAXstations, and fantasize
about buying one. Maybe one day I'll actually pull the trigger.

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.

~~~
zargon
It was 20 years ago that I bought my first VAXstation 3100 on eBay for under
$100. Later got a VAXstation 4000 and an AlphaServer 2100. Got rid of them all
during a period of downsizing. Along with some nice terminals and other DEC
equipment. Kinda regret that now.

------
thomasjudge
A little off topic, but if you haven't read this story, it's kind of amusing
(relevance is date functions in Excel)

[https://www.joelonsoftware.com/2006/06/16/my-first-billg-
rev...](https://www.joelonsoftware.com/2006/06/16/my-first-billg-review/)

------
waynecochran

        > The three cycles are 15, 19, and 28 years long.
    

Where did these numbers come from?

~~~
tingletech
28 (solar cycle) × 19 (lunar cycle) × 15 (indiction cycle) = 7980 years

[https://en.wikipedia.org/wiki/Julian_day](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.

------
kstenerud
I used a base year of 2000 in my compact date formats, one because it allows
hundreds of thousands of years, and the other because years closer to zero can
be stored in less bits:

[https://github.com/kstenerud/smalltime](https://github.com/kstenerud/smalltime)

[https://github.com/kstenerud/compact-
time](https://github.com/kstenerud/compact-time)

