Post by Rich Alderson Post by Michael Moroney Post by Rich Alderson Post by Michael Moroney
I do believe that, looking back 40 years, it was wrong to have VMS use
local time internally instead of using UTC (GMT is an obsolete term).
Instead of setting EXE$GQ_SYSTIME back and forward as places go on and off
summer time causes many issues, instead of just changing a system-wide
"local time offset" cell. Ideally, local time would be derived by adding
EXE$GQ_SYSTIME to the local offset, and summer time simply changes the
I also agree the new file system is not the place to do this, it would
become part of a crazy quilt of hack patches.
All right, I know that I must seem like a 36-bit bigot in this newgroup, but
did VMS really not follow the example of TOPS-20 in this? Even Tops-10
adopted the Julian Day 2,500,000.5 as the epoch eventually. Does the
magical date "November 17, 1858, at midnight GMT" have no meaning to VMS?
I am not talking about the base date. I am talking about how to deal
with winter/summer time and the effects of the time jumping forward or
(especially) backward in EXE$GQ_SYSTIME on things, or the exact meaning
of the time of a file timestamped 29-FEB-2016 01:23:45.67, as there are
no clues to the timezone it was written or summer or winter time etc.
Nothing to do with the choice of the base date.
That was my point about TOPS-20: File dates are maintained as a 36 bit word,
left half the integer number of days after November 17, 1858, and the right
half the fraction of a day since midnight. Time zone, summer/winter time,
etc., are completely irrelevant to the value stored: If a file is saved in
Seattle, dumped to tape, and restored in London, how the time and date are
displayed is irrelevant--it's the internal representation which rules.
And in VMS it's the number of 100ns increments since epoch.
That is actually better than the TOPS-20 solution of keeping the date in
the left halfword, and the time for that date in the right.
This really should be obvious, but I'll point it out anyway.
If you use local time, the date is not fixed. If I write a file on
Jan-1, 2017, at 01:00 (local time, one hour after midnight for me in
Switzerland), the time stamp for that file, for someone in Seattle, is
So, having the date and time as separate values means you get into even
more tricky computations when figuring out time. And as far as I
remember, TOPS-20 do not have a clue which time zone I am in to start
with, so it keeps just as little track of this information as VMS does.
VMS is atleast better in that all time is at least expressed as a
continuous incrementing number from the epoch. So, moving that time
forward or backward a number of hours is atleast just one simple
arithmetic addition or substraction. With TOPS-20, it becomes much less
so, unless the fractions of a day since midnight in TOPS-20 are
expressed as a fraction of 2^18, so that 0 is midnight, and 262137 is
one tick away from next midnight. But then you instead have a very funny
time base of 2^18 clock ticks in a day, which becomes ugly to translate
to hours, minutes, seconds, and so on...
Post by Rich Alderson
And the operating system takes care of that, with input and output system calls
and monitor internal tables of beginnings and endings of different time offsets
all the way back to the Great War.
Jeez. MRC was right.
MRC certainly had lots of good points. But in this case, I think you
And for the record, I think it would be nice if VMS switched to a UTC
based time. But I understand if this would not be the top priority of
things to do.
But the work might be both less and more than people expect.
If you switch to a UTC based time, everything else internal will pretty
much work right already, including file system.
What needs to be fixed is anything that reads out or pass in the time.
That would be things like the system call to read the system time, sets
system time, reads and sets file timestamps, and any kind of scheduling
requests that use absolute time.
All these calls will need to be extended to correct for time zone
And then you probably want to introduce a set of new system calls that
would read out and pass in times without adjusting for time zones.
So, all current system calls would still give local time, just like they
always did. It's just that you'd have an additional layer of time
translations involved in them, to actually get the local time.
Using a logical name to define the TZ offset would be a neat way of
dealing with it. You could then have a system logical for this, and
people who wanted to, could have their own, which overrides the system one.
But all this are just ideas and thoughts...
I've been thinking about doing this for RSX, but it's a bit more messy
in RSX, since time is normally kept in a much uglier format (RSX
normally keeps it as YYMMMDDhhmmss in text for files, and a somewhat
similar format, but binary, for the system in general, so it becomes
much more expensive to do calculations on it, and memory is always a
concern on a PDP-11).
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol