Discussion:
New VMS filesystem - will it use local or GMT timestamps ?
(too old to reply)
Simon Clubley
2017-12-03 15:26:27 UTC
Permalink
[This is just something that occurred to me while looking at something
else. I don't recall seeing this discussed so apologies if it has been.]

Will the new VMS filesystem use the local system time on its timestamps
or will it use GMT and then convert to local time from there ?

If it does use the local system time, will it also store away the
timezone offset active at the point the timestamp was created ?

In the latter case, this would be the current numeric offset (+0100 for
example) and not the actual timezone identifier such as BST/EST/etc.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Robert A. Brooks
2017-12-03 19:47:37 UTC
Permalink
Post by Simon Clubley
Will the new VMS filesystem use the local system time on its timestamps
or will it use GMT and then convert to local time from there ?
I don't recall seeing anything in the design specification we're working
with that discusses the use of GMT.
Post by Simon Clubley
If it does use the local system time, will it also store away the
timezone offset active at the point the timestamp was created ?
I doubt it. If the timekeeping mechanism within VMS is to be modernized,
it would have to be a system-wide endeavor. Simply altering the file system
and not touching the myriad utilities involved that interpret and display
the time wouldn't help much.

While it would be a "nice-to-have", I think we have more pressing issues.
--
-- Rob
Simon Clubley
2017-12-04 01:37:52 UTC
Permalink
Post by Robert A. Brooks
Post by Simon Clubley
Will the new VMS filesystem use the local system time on its timestamps
or will it use GMT and then convert to local time from there ?
I don't recall seeing anything in the design specification we're working
with that discusses the use of GMT.
Post by Simon Clubley
If it does use the local system time, will it also store away the
timezone offset active at the point the timestamp was created ?
I doubt it. If the timekeeping mechanism within VMS is to be modernized,
it would have to be a system-wide endeavor. Simply altering the file system
and not touching the myriad utilities involved that interpret and display
the time wouldn't help much.
While it would be a "nice-to-have", I think we have more pressing issues.
I agree now I know it's not GMT based. Pity though, as it would
have been a nice early step on the way to having GMT based
filesystems in VMS.

Thanks for the feedback,

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Michael Moroney
2017-12-04 16:47:49 UTC
Permalink
Post by Simon Clubley
Post by Robert A. Brooks
Post by Simon Clubley
Will the new VMS filesystem use the local system time on its timestamps
or will it use GMT and then convert to local time from there ?
I don't recall seeing anything in the design specification we're working
with that discusses the use of GMT.
Post by Simon Clubley
If it does use the local system time, will it also store away the
timezone offset active at the point the timestamp was created ?
I doubt it. If the timekeeping mechanism within VMS is to be modernized,
it would have to be a system-wide endeavor. Simply altering the file system
and not touching the myriad utilities involved that interpret and display
the time wouldn't help much.
While it would be a "nice-to-have", I think we have more pressing issues.
I agree now I know it's not GMT based. Pity though, as it would
have been a nice early step on the way to having GMT based
filesystems in VMS.
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
local offset.

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.
Rich Alderson
2017-12-04 20:14:04 UTC
Permalink
Post by Michael Moroney
Post by Simon Clubley
Post by Robert A. Brooks
Post by Simon Clubley
Will the new VMS filesystem use the local system time on its timestamps
or will it use GMT and then convert to local time from there ?
I don't recall seeing anything in the design specification we're working
with that discusses the use of GMT.
Post by Simon Clubley
If it does use the local system time, will it also store away the
timezone offset active at the point the timestamp was created ?
I doubt it. If the timekeeping mechanism within VMS is to be modernized,
it would have to be a system-wide endeavor. Simply altering the file
system and not touching the myriad utilities involved that interpret and
display the time wouldn't help much.
While it would be a "nice-to-have", I think we have more pressing issues.
I agree now I know it's not GMT based. Pity though, as it would
have been a nice early step on the way to having GMT based
filesystems in VMS.
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
local offset.
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?

WTF, over?
--
Rich Alderson ***@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
Simon Clubley
2017-12-04 22:26:04 UTC
Permalink
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
local offset.
In any redesign, it would be nice if any local offset was a process
level value instead of a system level value. Not all processes will be
logging in from the same timezone.

$ set response/mode=good_natured

BTW, obsolete maybe, unless of course you live in the country which
gave GMT to the world... :-)

(Everyone I know talks about GMT and not UTC in everyday life.)
Post by Rich Alderson
Post by Michael Moroney
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?
WTF, over?
We are not talking about the base date. We are talking about how
VMS handles the transition when DST occurs and Unix does a far
better job of this than VMS currently does.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Michael Moroney
2017-12-05 06:14:05 UTC
Permalink
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
local offset.
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?
WTF, over?
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.

I once helped maintain a fire department dispatch system that ran on VMS.
Setting the time back every November as daylight saving time ended was a
big headache for them. The software itself also dealt with it poorly. They
had to wait until things were quiet, stop the software, set the time and
restart the SW.

As to the VMS base date itself: Very very minor detail but perhaps a
better choice may have been the earliest switch to the Gregorian calendar
as VMS could then represent more dates in the past, at the expense of
what, only going to the year 29000 instead of 31000? (an earlier base
date won't help since Julian calendar dates would be inaccurate)

And to Simon: Yes, it should work like logical names. A system wide
offset but the users could set their own that overrode that.
David Froble
2017-12-05 16:45:19 UTC
Permalink
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
local offset.
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?
WTF, over?
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.
I once helped maintain a fire department dispatch system that ran on VMS.
Setting the time back every November as daylight saving time ended was a
big headache for them. The software itself also dealt with it poorly. They
had to wait until things were quiet, stop the software, set the time and
restart the SW.
As to the VMS base date itself: Very very minor detail but perhaps a
better choice may have been the earliest switch to the Gregorian calendar
as VMS could then represent more dates in the past, at the expense of
what, only going to the year 29000 instead of 31000? (an earlier base
date won't help since Julian calendar dates would be inaccurate)
And to Simon: Yes, it should work like logical names. A system wide
offset but the users could set their own that overrode that.
A few thoughts.

While using UTC would require massive changes, would it be a good idea to right
now start recording the current local date and time, and in addition the UTC
date and time, the UTC offset, and the daylight savings time offset? And
perhaps more. The data would then be there as additional capabilities are
implemented.
t***@glaver.org
2017-12-05 23:27:37 UTC
Permalink
Post by David Froble
While using UTC would require massive changes, would it be a good idea to right
now start recording the current local date and time, and in addition the UTC
date and time, the UTC offset, and the daylight savings time offset? And
perhaps more. The data would then be there as additional capabilities are
implemented.
Certainly leaving a bunch of extra reserved space (marked "reserved - must be zero") in the directory entry (or whatever the equivalent in the new filesystem is) would be useful. I would even suggest padding out any 32- or 64-bit values to a full 128 bits to make future expansion easier. Speaking of values, might the new filesystem store them in an endian-independent manner? The CPU cost of shuffling bytes should be pretty low these days.
Rich Alderson
2017-12-06 20:38:57 UTC
Permalink
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
local offset.
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?
WTF, over?
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 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.
--
Rich Alderson ***@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
Michael Moroney
2017-12-07 19:21:09 UTC
Permalink
Post by Rich Alderson
Post by Michael Moroney
Post by Rich Alderson
WTF, over?
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.
I am unfamiliar with TOPS-20.
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.
What happens when a system is located in a place where it switches from
daylight standard time to standard time, or the opposite? What changes
and what doesn't?

Assuming the system time most users see is the local time zone.
Stephen Hoffman
2017-12-07 19:59:26 UTC
Permalink
Post by Michael Moroney
Post by Rich Alderson
Post by Michael Moroney
Post by Rich Alderson
WTF, over?
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.
I am unfamiliar with TOPS-20.
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.
What happens when a system is located in a place where it switches from
daylight standard time to standard time, or the opposite? What changes
and what doesn't?
Assuming the system time most users see is the local time zone.
TOPS and OpenVMS all use the same base date.
http://www.inwap.com/pdp10/usenet/julian-day
TOPS and OpenVMS also all use local time as the base time. Not UTC nor GMT.
BTW: Greenwich Mean Time (GMT) is a more accurate day than is Universal
Coordinated Time (UTC), and UTC is more accurate than GMT. Which of
these two is true in your particular case depends on what you are
seeking to measure.
TOPS knows nothing of timezones, and OpenVMS has... issues with its
timezones and TDF implementation.
OpenVMS development has tried to avoid switching to UTC for the local
base time, while also adding TDF support.
Which means that the timestamps on all the objects are indeterminate if
you don't know the timezone the timestamp applies to, and it means that
the DST switchover can be "entertaining."
So yes, the timestamps use the base date. But without an associated
TDF and without the use of UTC as the base time, you effectively have
to know where the file was written in order to know when the file was
written.
In OpenVMS terms, the value in EXE$GQ_SYSTIME or the native time values
that are so often attached to files and other objects are ambiguous
without also knowing EXE$GQ_TDF and the associated timezone location.

Related:
http://davedelong.tumblr.com/post/140216824433/intercalation
http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time

http://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-about-time

etc.

Then there's the always-fun case of time and timekeeping in distributed
systems:
https://queue.acm.org/detail.cfm?id=2745385
...and in clusters, for that matter.
--
Pure Personal Opinion | HoffmanLabs LLC
Rich Alderson
2017-12-07 20:53:58 UTC
Permalink
Post by Stephen Hoffman
OpenVMS development has tried to avoid switching to UTC for the local
base time, while also adding TDF support.
Which means that the timestamps on all the objects are indeterminate if
you don't know the timezone the timestamp applies to, and it means that
the DST switchover can be "entertaining."
So yes, the timestamps use the base date. But without an associated
TDF and without the use of UTC as the base time, you effectively have
to know where the file was written in order to know when the file was
written.
In OpenVMS terms, the value in EXE$GQ_SYSTIME or the native time values
that are so often attached to files and other objects are ambiguous
without also knowing EXE$GQ_TDF and the associated timezone location.
O. M. F. G.
--
Rich Alderson ***@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
Johnny Billquist
2017-12-08 15:43:17 UTC
Permalink
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
local offset.
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?
WTF, over?
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
31-Dec-2017, 16:00.

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


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
difference.
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
Johnny
--
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
Johnny Billquist
2017-12-08 16:06:10 UTC
Permalink
Post by Johnny Billquist
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
local offset.
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?
WTF, over?
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
31-Dec-2017, 16:00.
Argh! 31-Dec-2016, 16:00.

Johnny
Post by Johnny Billquist
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...
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
missed something.
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
difference.
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
  Johnny
--
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
Rich Alderson
2017-12-08 20:30:52 UTC
Permalink
Post by Johnny Billquist
Post by Rich Alderson
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
31-Dec-2017, 16:00.
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...
The fractional day is indeed n/2^18 clock ticks. Both halves increase
monotonically (that is, the clock overflows from the right halfword to the left
at midnight and the day number increases). Keeping an integral number of days
in the left half *simplifies* a lot of the date math, but in any case, the
hours/minutes/seconds argument is a straw man: The code implementing some
system calls has to do some relatively trivial math; so what? So does the code
implementing (hypothetical?) calls in VMS, since I doubt that there is hardware
in the VAX, Alpha, Itanium, or x86_64 to do n:24:60:60.
Post by Johnny Billquist
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.
(In hardware, the system clock is actually a doubleword integer number of clock
ticks since last power-on, but that's a mere detail. The monitor takes care
of converting to the canonical time format for anything user-facing.)
Post by Johnny Billquist
Post by Rich Alderson
Jeez. MRC was right.
MRC certainly had lots of good points. But in this case, I think you
missed something.
;-) Probably not.
Post by Johnny Billquist
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
difference.
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.
Exactly as happens in TOPS-20. (Well, not a system logical for the time zone,
because TOPS-20 logical names are more limited than VMS--see, I can admit it
when TOPS-20 fails.)
--
Rich Alderson ***@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
David Froble
2017-12-09 04:27:15 UTC
Permalink
Post by Rich Alderson
Post by Johnny Billquist
Post by Rich Alderson
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
31-Dec-2017, 16:00.
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...
The fractional day is indeed n/2^18 clock ticks. Both halves increase
monotonically (that is, the clock overflows from the right halfword to the left
at midnight and the day number increases). Keeping an integral number of days
in the left half *simplifies* a lot of the date math, but in any case, the
hours/minutes/seconds argument is a straw man: The code implementing some
system calls has to do some relatively trivial math; so what? So does the code
implementing (hypothetical?) calls in VMS, since I doubt that there is hardware
in the VAX, Alpha, Itanium, or x86_64 to do n:24:60:60.
Post by Johnny Billquist
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.
(In hardware, the system clock is actually a doubleword integer number of clock
ticks since last power-on, but that's a mere detail. The monitor takes care
of converting to the canonical time format for anything user-facing.)
Post by Johnny Billquist
Post by Rich Alderson
Jeez. MRC was right.
MRC certainly had lots of good points. But in this case, I think you
missed something.
;-) Probably not.
Post by Johnny Billquist
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
difference.
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.
Exactly as happens in TOPS-20. (Well, not a system logical for the time zone,
because TOPS-20 logical names are more limited than VMS--see, I can admit it
when TOPS-20 fails.)
In all fairness, I'd ask when development of TOPS-20 ended?

That's a bit like comparing a 110 ns Alpha (I believe that was the last process
size) with a current 32 ns processor.

Perhaps TOPS-20 might have gotten many things "right" ...
Jan-Erik Soderholm
2017-12-09 10:35:17 UTC
Permalink
Post by David Froble
That's a bit like comparing a 110 ns Alpha (I believe that was the last
process size) with a current 32 ns processor.
nm?
David Froble
2017-12-09 19:27:16 UTC
Permalink
Post by David Froble
That's a bit like comparing a 110 ns Alpha (I believe that was the
last process size) with a current 32 ns processor.
nm?
Yeah, old age and senility strike again.

:-)
Stephen Hoffman
2017-12-10 01:01:41 UTC
Permalink
Post by David Froble
Post by David Froble
That's a bit like comparing a 110 ns Alpha (I believe that was the last
process size) with a current 32 ns processor.
nm?
Yeah, old age and senility strike again.
:-)
Processors with 10 nm feature sizes are now in common use.

😉
--
Pure Personal Opinion | HoffmanLabs LLC
Johnny Billquist
2017-12-09 13:51:23 UTC
Permalink
Post by Rich Alderson
Post by Johnny Billquist
Post by Rich Alderson
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
31-Dec-2017, 16:00.
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...
The fractional day is indeed n/2^18 clock ticks. Both halves increase
monotonically (that is, the clock overflows from the right halfword to the left
at midnight and the day number increases). Keeping an integral number of days
in the left half *simplifies* a lot of the date math, but in any case, the
hours/minutes/seconds argument is a straw man: The code implementing some
system calls has to do some relatively trivial math; so what? So does the code
implementing (hypothetical?) calls in VMS, since I doubt that there is hardware
in the VAX, Alpha, Itanium, or x86_64 to do n:24:60:60.
Ah. I didn't expect TOPS-20 to count one day as 2^18 increments. But
then it for most purposes becomes just as easy/hard as for VMS.

But this is still a separate issue to the question of time zones.
Post by Rich Alderson
Post by Johnny Billquist
Post by Rich Alderson
Jeez. MRC was right.
MRC certainly had lots of good points. But in this case, I think you
missed something.
;-) Probably not.
So then you are saying I missed something. :-)
So, how/where does TOPS-20 keep track of which timezone I am in? I can't
remember seeing anything about this anywhere.

Johnny
--
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
Johnny Billquist
2017-12-08 15:20:51 UTC
Permalink
Post by Rich Alderson
Post by Michael Moroney
Post by Simon Clubley
Post by Robert A. Brooks
Post by Simon Clubley
Will the new VMS filesystem use the local system time on its timestamps
or will it use GMT and then convert to local time from there ?
I don't recall seeing anything in the design specification we're working
with that discusses the use of GMT.
Post by Simon Clubley
If it does use the local system time, will it also store away the
timezone offset active at the point the timestamp was created ?
I doubt it. If the timekeeping mechanism within VMS is to be modernized,
it would have to be a system-wide endeavor. Simply altering the file
system and not touching the myriad utilities involved that interpret and
display the time wouldn't help much.
While it would be a "nice-to-have", I think we have more pressing issues.
I agree now I know it's not GMT based. Pity though, as it would
have been a nice early step on the way to having GMT based
filesystems in VMS.
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
local offset.
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?
WTF, over?
Uh. Rich, I believe TOPS-20 also use local time, unless my brain really
have some bit rot...
This is not about what the epoch is, but how to represent that you are
in a specific time zone.
I don't think DEC used UTC in any system, but always used local time.

Johnny
--
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
Rich Alderson
2017-12-08 20:13:54 UTC
Permalink
Post by Johnny Billquist
Uh. Rich, I believe TOPS-20 also use local time, unless my brain really
have some bit rot...
This is not about what the epoch is, but how to represent that you are
in a specific time zone.
I don't think DEC used UTC in any system, but always used local time.
Hi, Johnny!

TOPS-20 uses UTC internally; the system manager defines the local time zone
in *-CONFIG.CMD,[1] which is read at system startup.

Tops-10 (which despite the name, as you know, is completely unrelated) uses
local time, with a time base of midnight 1-Jan-1964, with time only kept for
some things but not everything. And people complain about VMS!

[1] The beginning of the filename is the major version number of the monitor,
so on the Toad systems at the museum and on emulators running the Panda
distribution monitor it's "7"; on KS-10 based systems it's "4".
--
Rich Alderson ***@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
Johnny Billquist
2017-12-09 13:59:11 UTC
Permalink
Post by Rich Alderson
Post by Johnny Billquist
Uh. Rich, I believe TOPS-20 also use local time, unless my brain really
have some bit rot...
This is not about what the epoch is, but how to represent that you are
in a specific time zone.
I don't think DEC used UTC in any system, but always used local time.
Hi, Johnny!
TOPS-20 uses UTC internally; the system manager defines the local time zone
in *-CONFIG.CMD,[1] which is read at system startup.
I'll be damned. I had totally missed/forgotten that. Looked now, and
indeed, you do have timezone and daylight definitions in there.

Admittedly, I suspect it's less good than the Unix timezone handling,
but then it definitely looks better than VMS. Nice.
Post by Rich Alderson
Tops-10 (which despite the name, as you know, is completely unrelated) uses
local time, with a time base of midnight 1-Jan-1964, with time only kept for
some things but not everything. And people complain about VMS!
Heh! Tops-10 does not surprise me at all. ;-) (And we both know what MRC
thought of that one...)

Johnny
--
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
Dirk Munk
2017-12-05 23:35:40 UTC
Permalink
Post by Michael Moroney
Post by Simon Clubley
Post by Robert A. Brooks
Post by Simon Clubley
Will the new VMS filesystem use the local system time on its timestamps
or will it use GMT and then convert to local time from there ?
I don't recall seeing anything in the design specification we're working
with that discusses the use of GMT.
Post by Simon Clubley
If it does use the local system time, will it also store away the
timezone offset active at the point the timestamp was created ?
I doubt it. If the timekeeping mechanism within VMS is to be modernized,
it would have to be a system-wide endeavor. Simply altering the file system
and not touching the myriad utilities involved that interpret and display
the time wouldn't help much.
While it would be a "nice-to-have", I think we have more pressing issues.
I agree now I know it's not GMT based. Pity though, as it would
have been a nice early step on the way to having GMT based
filesystems in VMS.
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
local offset.
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.
DECnet Phase V / OSI has always been using UTC timestamps. I see no
reason why it could not be implemented in a file system as well.
Simon Clubley
2017-12-05 23:43:04 UTC
Permalink
Post by Dirk Munk
DECnet Phase V / OSI has always been using UTC timestamps. I see no
reason why it could not be implemented in a file system as well.
The filesystem is only part of it; all the other date/time code would
probably need to be touched as well.

It also has some other implications as well. For example, if you allow
per process timezones, do you now need to display timestamps with
a timezone suffix added (just like you do on Unix) ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
David Froble
2017-12-06 04:44:54 UTC
Permalink
Post by Simon Clubley
Post by Dirk Munk
DECnet Phase V / OSI has always been using UTC timestamps. I see no
reason why it could not be implemented in a file system as well.
The filesystem is only part of it; all the other date/time code would
probably need to be touched as well.
It also has some other implications as well. For example, if you allow
per process timezones, do you now need to display timestamps with
a timezone suffix added (just like you do on Unix) ?
Simon.
I don't see why it could not be an option.

And then the question will come up, what happens in a cluster ...

And in the background we hear Steve chanting "bust it", "bust it" ...

:-)
j***@yahoo.co.uk
2017-12-06 08:33:33 UTC
Permalink
Post by David Froble
Post by Simon Clubley
Post by Dirk Munk
DECnet Phase V / OSI has always been using UTC timestamps. I see no
reason why it could not be implemented in a file system as well.
The filesystem is only part of it; all the other date/time code would
probably need to be touched as well.
It also has some other implications as well. For example, if you allow
per process timezones, do you now need to display timestamps with
a timezone suffix added (just like you do on Unix) ?
Simon.
I don't see why it could not be an option.
And then the question will come up, what happens in a cluster ...
And in the background we hear Steve chanting "bust it", "bust it" ...
:-)
Fakeable (e.g. per-process) VMS time values have been an
available option for decades, although not shipped as
part of the base OS.

E.g. it's historically been quite useful for testing
of time-dependent software without clobbering the time
system-wide.

If I remember rightly, code to enable this trick was
available from some of the more interesting third
parties, maybe even via some DEC services outlets.
E.g. The kind of outfits that might have sold stuff
like PEEK and SPY?

As regards displaying the 'new' stuff: A variety of
standardised APIs etc have been defined for
accessing (and displaying) the timezone in a useful
way: this is in general a solved problem, not too
much wheel reinvention is required. Some options are
are part of open standards (eg POSIX), some may be
part of language standards.

It'd be handy if VMS's existing time-related services
were aware of this in a sensible way. They're mostly
starting from a good place, unlike e.g. the amazingly
inconsistent selection of time-related stuff in
widespread use on Window boxes.

Have a lot of fun.
Simon Clubley
2017-12-06 13:17:08 UTC
Permalink
Post by David Froble
Post by Simon Clubley
The filesystem is only part of it; all the other date/time code would
probably need to be touched as well.
It also has some other implications as well. For example, if you allow
per process timezones, do you now need to display timestamps with
a timezone suffix added (just like you do on Unix) ?
I don't see why it could not be an option.
And then the question will come up, what happens in a cluster ...
That's the beauty of this - it should make absolutely no difference
in a cluster at all.

You could have different nodes of a cluster in different timezones,
with each node set to the timezone for its location and then you could
have a user logging in from yet another timezone with the process
specific timezone set to the user's location.

The reason why all this just works is because they would all be using
the same time (GMT/UTC). In a proper GMT/UTC system (such as that
implemented on Unix), the timezone specific time is just a view into
the GMT/UTC base time.

BTW, I wonder what the record is for the number of different timezones
that the nodes of a share-everything VMScluster occupies.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Jan-Erik Soderholm
2017-12-06 13:30:25 UTC
Permalink
Post by Simon Clubley
Post by David Froble
Post by Simon Clubley
The filesystem is only part of it; all the other date/time code would
probably need to be touched as well.
It also has some other implications as well. For example, if you allow
per process timezones, do you now need to display timestamps with
a timezone suffix added (just like you do on Unix) ?
I don't see why it could not be an option.
And then the question will come up, what happens in a cluster ...
That's the beauty of this - it should make absolutely no difference
in a cluster at all.
You could have different nodes of a cluster in different timezones,
with each node set to the timezone for its location and then you could
have a user logging in from yet another timezone with the process
specific timezone set to the user's location.
The reason why all this just works is because they would all be using
the same time (GMT/UTC). In a proper GMT/UTC system (such as that
implemented on Unix), the timezone specific time is just a view into
the GMT/UTC base time.
BTW, I wonder what the record is for the number of different timezones
that the nodes of a share-everything VMScluster occupies.
Simon.
So two users in two different timezones doing a DIR on the *same
file(s)* would see different timestamp(s) on the files?

And the output from DIR /SINCE or /BEFORE using a specific timestamp
could be different for different users on the same system? That is,
if they are in different timezones. That is, if they specify the
same absolute time in the DIR command, they would/could get
different output?

Or would the display always be UTC with a timezone code appended?
What would you then specify in the /BEFORE and /AFTER switches?
UTC time including timezone?
Simon Clubley
2017-12-06 14:08:41 UTC
Permalink
Post by Jan-Erik Soderholm
So two users in two different timezones doing a DIR on the *same
file(s)* would see different timestamp(s) on the files?
No. They would see two different _views_ of the _same_ GMT/UTC timestamp.
Post by Jan-Erik Soderholm
And the output from DIR /SINCE or /BEFORE using a specific timestamp
could be different for different users on the same system? That is,
if they are in different timezones. That is, if they specify the
same absolute time in the DIR command, they would/could get
different output?
Yes. However, don't think of it as an absolute time. Think of it as
the local time in the location that the person is entering the command.
Post by Jan-Erik Soderholm
Or would the display always be UTC with a timezone code appended?
No, it's the time in the local timezone with the local timezone code
or offset appended. Try doing an "ls -l" and then an "ls -l --full"
on Linux to see an example. Then repeat those commands but specify
TZ="EST" (for example) as a prefix and watch the times displayed change.
Post by Jan-Erik Soderholm
What would you then specify in the /BEFORE and /AFTER switches?
UTC time including timezone?
A time which would be assumed to be the local time unless you override
it with a specific timezone.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Jan-Erik Soderholm
2017-12-06 14:50:59 UTC
Permalink
Post by Simon Clubley
Post by Jan-Erik Soderholm
So two users in two different timezones doing a DIR on the *same
file(s)* would see different timestamp(s) on the files?
No. They would see two different _views_ of the _same_ GMT/UTC timestamp.
So they would see differnt timestamps then. OK. I do not care if
what is displayed on screen is a "view", it is what is actually
displayed on-screen I asked about.
Post by Simon Clubley
Post by Jan-Erik Soderholm
And the output from DIR /SINCE or /BEFORE using a specific timestamp
could be different for different users on the same system? That is,
if they are in different timezones. That is, if they specify the
same absolute time in the DIR command, they would/could get
different output?
Yes. However, don't think of it as an absolute time. Think of it as
the local time in the location that the person is entering the command.
OK. So if one user sees something weird, and mails his output, including
the DIR command used, the other used cannot reproduce the output using
the same DIR command without fiddling with timezones, right?
Post by Simon Clubley
Post by Jan-Erik Soderholm
Or would the display always be UTC with a timezone code appended?
No, it's the time in the local timezone with the local timezone code
or offset appended. Try doing an "ls -l" and then an "ls -l --full"
on Linux to see an example.
Show me an example instead. I have never used a Linux system.
John Reagan
2017-12-06 15:36:14 UTC
Permalink
Post by Jan-Erik Soderholm
Post by Simon Clubley
No, it's the time in the local timezone with the local timezone code
or offset appended. Try doing an "ls -l" and then an "ls -l --full"
on Linux to see an example.
Show me an example instead. I have never used a Linux system.
[***@exec-proliant1 ~]$ touch aaa.c
[***@exec-proliant1 ~]$ ls -l aaa.c
-rw-rw-r--. 1 jreagan jreagan 0 Dec 6 10:35 aaa.c
[***@exec-proliant1 ~]$ ls -l --full aaa.c
-rw-rw-r--. 1 jreagan jreagan 0 2017-12-06 10:35:06.288062491 -0500 aaa.c
[***@exec-proliant1 ~]$ export TZ=America/Los_Angeles
[***@exec-proliant1 ~]$ ls -l aaa.c
-rw-rw-r--. 1 jreagan jreagan 0 Dec 6 07:35 aaa.c
[***@exec-proliant1 ~]$ ls -l --full aaa.c
-rw-rw-r--. 1 jreagan jreagan 0 2017-12-06 07:35:06.288062491 -0800 aaa.c
Jan-Erik Soderholm
2017-12-06 15:52:44 UTC
Permalink
Post by John Reagan
Post by Jan-Erik Soderholm
Post by Simon Clubley
No, it's the time in the local timezone with the local timezone code
or offset appended. Try doing an "ls -l" and then an "ls -l --full"
on Linux to see an example.
Show me an example instead. I have never used a Linux system.
-rw-rw-r--. 1 jreagan jreagan 0 Dec 6 10:35 aaa.c
-rw-rw-r--. 1 jreagan jreagan 0 2017-12-06 10:35:06.288062491 -0500 aaa.c
-rw-rw-r--. 1 jreagan jreagan 0 Dec 6 07:35 aaa.c
-rw-rw-r--. 1 jreagan jreagan 0 2017-12-06 07:35:06.288062491 -0800 aaa.c
OK, thanks. Not much of an /full output, is it? :-)

Anyway. So the diff against UTC is that -0500 or -0800. OK.
If someone else from another TZ would be logged in to the same
system, he would/could see another timestamp on the file. If
he used his own local TZ.

Fine then. I get it. I also see all implications with such things
like the quemgr and similar. Jobs on timed-release, when should they
be released. According to the UTC time or to the new local time?

The positive side is of course that the core time of the system
will always be moving "forward" at the same speed. And the "real"
timestamps recorded in the files also. But the displayed time
will still move according to the changes of DST, just as today
in VMS.

I do not see a major overhaul of this coming soon.
j***@yahoo.co.uk
2017-12-06 16:29:36 UTC
Permalink
Post by Jan-Erik Soderholm
Post by John Reagan
Post by Jan-Erik Soderholm
Post by Simon Clubley
No, it's the time in the local timezone with the local timezone code
or offset appended. Try doing an "ls -l" and then an "ls -l --full"
on Linux to see an example.
Show me an example instead. I have never used a Linux system.
-rw-rw-r--. 1 jreagan jreagan 0 Dec 6 10:35 aaa.c
-rw-rw-r--. 1 jreagan jreagan 0 2017-12-06 10:35:06.288062491 -0500 aaa.c
-rw-rw-r--. 1 jreagan jreagan 0 Dec 6 07:35 aaa.c
-rw-rw-r--. 1 jreagan jreagan 0 2017-12-06 07:35:06.288062491 -0800 aaa.c
OK, thanks. Not much of an /full output, is it? :-)
Anyway. So the diff against UTC is that -0500 or -0800. OK.
If someone else from another TZ would be logged in to the same
system, he would/could see another timestamp on the file. If
he used his own local TZ.
Fine then. I get it. I also see all implications with such things
like the quemgr and similar. Jobs on timed-release, when should they
be released. According to the UTC time or to the new local time?
The positive side is of course that the core time of the system
will always be moving "forward" at the same speed. And the "real"
timestamps recorded in the files also. But the displayed time
will still move according to the changes of DST, just as today
in VMS.
I do not see a major overhaul of this coming soon.
You get it. There's possibly even more, such as within
a cluster, various things (used to?) rely on nodes having
a reasonably consistent idea of what time it is. Does
that still feature in this kind of discussion? Don't
know.

Doing it all properly will need some thought, but even if
now isn't the right er time for VSI to do the job in full
(which it probably isn't) the x86 port might be an
opportunity to do a bit of research and planning and
discussion and maybe setting out some "reserved for future
expansion" stuff.

The displayed time format for any given application setup
can eventually become a customer/user choice, much as it
has been (to an extent) for ages courtesy of VMS
facilities provided by LIB$DT_FORMAT() and friends. See
e.g. VMS Programming Concepts manual, section titled
Date/Time Formatting Routines. Here's an example:
http://h41379.www4.hpe.com/doc/82final/5841/5841pro_077.html

Some of us still remember the exciting surprises that
can be had by running one OS and then a different one
on the same box, when the OSes in question interpret
the hardware ("TOY") clock in different ways.

Some of us are still having fun trying to sync files
between FAT32 and NTFS filesystems, which can be fun.

Lots of interesting things to think about.
Simon Clubley
2017-12-06 19:08:10 UTC
Permalink
Post by j***@yahoo.co.uk
Post by Jan-Erik Soderholm
Anyway. So the diff against UTC is that -0500 or -0800. OK.
If someone else from another TZ would be logged in to the same
system, he would/could see another timestamp on the file. If
he used his own local TZ.
Fine then. I get it. I also see all implications with such things
like the quemgr and similar. Jobs on timed-release, when should they
be released. According to the UTC time or to the new local time?
The positive side is of course that the core time of the system
will always be moving "forward" at the same speed. And the "real"
timestamps recorded in the files also. But the displayed time
will still move according to the changes of DST, just as today
in VMS.
I do not see a major overhaul of this coming soon.
You get it. There's possibly even more, such as within
a cluster, various things (used to?) rely on nodes having
a reasonably consistent idea of what time it is. Does
that still feature in this kind of discussion? Don't
know.
There are no "bad" implications for the queue manager or internal
cluster timekeeping with this approach - it is all internally
logical and consistent which is a lot better than the current
approach is.

This is the key point:

_All_ internal processing is done in GMT/UTC and anything you see
in your various command displays is merely a local timezone view
into the base GMT/UTC time.

Once you understand that, you will understand that there are no
"bad" implications for the queue manager or internal cluster
timekeeping.

Internal cluster timekeeping should always be done in GMT/UTC.

The release time for jobs submitted for timed release is always
converted to GMT/UTC before being stored in the queue manager
database. It doesn't matter if the user submitted a job using
the user's local time or specified a timezone - what's in the
queue manager is _always_ in GMT/UTC.

This means that if you are in the US and submit a job to run
two hours from now then that is what will show up in "show queue".

If someone in Japan looks at the same job, the display should
show the release time in terms of Japanese local time so the
person in Japan will see a local release time that is also
two hours from now.

Like I said, done properly, this is all beautifully elegant.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Jan-Erik Soderholm
2017-12-06 20:02:57 UTC
Permalink
Post by Simon Clubley
Post by j***@yahoo.co.uk
Post by Jan-Erik Soderholm
Anyway. So the diff against UTC is that -0500 or -0800. OK.
If someone else from another TZ would be logged in to the same
system, he would/could see another timestamp on the file. If
he used his own local TZ.
Fine then. I get it. I also see all implications with such things
like the quemgr and similar. Jobs on timed-release, when should they
be released. According to the UTC time or to the new local time?
The positive side is of course that the core time of the system
will always be moving "forward" at the same speed. And the "real"
timestamps recorded in the files also. But the displayed time
will still move according to the changes of DST, just as today
in VMS.
I do not see a major overhaul of this coming soon.
You get it. There's possibly even more, such as within
a cluster, various things (used to?) rely on nodes having
a reasonably consistent idea of what time it is. Does
that still feature in this kind of discussion? Don't
know.
There are no "bad" implications for the queue manager or internal
cluster timekeeping with this approach - it is all internally
logical and consistent which is a lot better than the current
approach is.
_All_ internal processing is done in GMT/UTC and anything you see
in your various command displays is merely a local timezone view
into the base GMT/UTC time.
Once you understand that, you will understand that there are no
"bad" implications for the queue manager or internal cluster
timekeeping.
Internal cluster timekeeping should always be done in GMT/UTC.
The release time for jobs submitted for timed release is always
converted to GMT/UTC before being stored in the queue manager
database. It doesn't matter if the user submitted a job using
the user's local time or specified a timezone - what's in the
queue manager is _always_ in GMT/UTC.
This means that if you are in the US and submit a job to run
two hours from now then that is what will show up in "show queue".
If someone in Japan looks at the same job, the display should
show the release time in terms of Japanese local time so the
person in Japan will see a local release time that is also
two hours from now.
And then, in between, the US switch to DST.

Should the job stay on the same US-local time (now a different
UTC time, and showing a different time for the Japan user)?

Or should it stay on the same UTC time (and showing a different
time for the original US submitter, but same for the Japan user)?

The first seems logical, keep the tiem the same for the original
submitter.

But what if the job was submitted by the Japan user? And the US
switch to DST. Then it feels that the second options seems logical
(still keeping the time the same for the original submitter).

The system might know who submitted the job, but does it know what
TZ he belongs to? And what if the US user *or* the Japan user submits
using /USER=xxx where xxx is some application specific user that
doesn't belong to any specific TZ? Should the entry then stay on the
same UTC time or move along with the new DST setting (that might not
be relevant for all users on the system anyway)?
Post by Simon Clubley
Like I said, done properly, this is all beautifully elegant.
Simon.
Paul Sture
2017-12-06 20:28:17 UTC
Permalink
<snip>
Post by Jan-Erik Soderholm
Post by Simon Clubley
This means that if you are in the US and submit a job to run
two hours from now then that is what will show up in "show queue".
If someone in Japan looks at the same job, the display should
show the release time in terms of Japanese local time so the
person in Japan will see a local release time that is also
two hours from now.
And then, in between, the US switch to DST.
Should the job stay on the same US-local time (now a different
UTC time, and showing a different time for the Japan user)?
Or should it stay on the same UTC time (and showing a different
time for the original US submitter, but same for the Japan user)?
The calculation should work out what the UTC time will be after
the DST change, and store that.

If a job specifying "Monday at 3am" is submitted on the Friday before
the clocks change on Sunday morning, the system knows that the time
change will occur and calculate the appropriate UTC time to store in the
queue, so that the job will indeed run on Monday at 3am.

Related is the problem of converting a historical set of dates and times
originally stored in local time to UTC. The DST offset at the given
date and time is taken into account and used in the conversion to UTV.

FWIW, here's an example of that conversion using PostgreSQL:

update some_table set utc_datetime = substr(datetime, 1, 10)|| ' ' ||
substr(datetime, 12,2) || ':' || substr(datetime, 14,2) || ':' ||
substr(datetime, 16,2) || ' Europe/Zurich';

There's probably a more elegant way of doing that, but it worked for
the task I had at the time.
--
Everybody has a testing environment. Some people are lucky enough to
have a totally separate environment to run production in.
Bill Gunshannon
2017-12-06 21:09:40 UTC
Permalink
Post by Paul Sture
<snip>
Post by Jan-Erik Soderholm
Post by Simon Clubley
This means that if you are in the US and submit a job to run
two hours from now then that is what will show up in "show queue".
If someone in Japan looks at the same job, the display should
show the release time in terms of Japanese local time so the
person in Japan will see a local release time that is also
two hours from now.
And then, in between, the US switch to DST.
Should the job stay on the same US-local time (now a different
UTC time, and showing a different time for the Japan user)?
Or should it stay on the same UTC time (and showing a different
time for the original US submitter, but same for the Japan user)?
The calculation should work out what the UTC time will be after
the DST change, and store that.
Or we could fix all of it by finally dumping the whole DST
BS. (as some places in the US now want to do!!) It would
have made no sense at the time it was supposed to have been
conceived and makes little if any sense today.

bill
Simon Clubley
2017-12-07 13:54:03 UTC
Permalink
Post by Bill Gunshannon
Or we could fix all of it by finally dumping the whole DST
BS. (as some places in the US now want to do!!) It would
have made no sense at the time it was supposed to have been
conceived and makes little if any sense today.
There are two problems here:

1) People live and work in different timezones.

2) Some timezones change their offset from GMT during the year.

Removing DST only fixes problem 2. You still have problem 1 to deal with.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Bill Gunshannon
2017-12-07 14:13:21 UTC
Permalink
Post by Simon Clubley
Post by Bill Gunshannon
Or we could fix all of it by finally dumping the whole DST
BS. (as some places in the US now want to do!!) It would
have made no sense at the time it was supposed to have been
conceived and makes little if any sense today.
1) People live and work in different timezones.
2) Some timezones change their offset from GMT during the year.
Removing DST only fixes problem 2. You still have problem 1 to deal with.
Yes, but fixing problem 2 doesn't cause additional problems and
it is half the stated problem.

One step at a time.

bill
Bill Gunshannon
2017-12-07 14:17:21 UTC
Permalink
Post by Simon Clubley
Post by Bill Gunshannon
Or we could fix all of it by finally dumping the whole DST
BS. (as some places in the US now want to do!!) It would
have made no sense at the time it was supposed to have been
conceived and makes little if any sense today.
1) People live and work in different timezones.
2) Some timezones change their offset from GMT during the year.
Removing DST only fixes problem 2. You still have problem 1 to deal with.
I should also have mentioned that eliminating DST eliminates
the inconsistent part of the problem. Timezones are constant
and well defined. Much easier to deal with than DST which is
not always an hour different and not controlled by well defined
geographic zones.

bill
Paul Sture
2017-12-07 15:08:20 UTC
Permalink
Timezones are constant and well defined.
Better than the DST mess, certainly, but not the whole story.
I did mention national boundaries changing.

Time to revisit this one, methinks:

"Falsehoods programmers believe about time"

<FalsehoodsAboutTime.com>
--
Everybody has a testing environment. Some people are lucky enough to
have a totally separate environment to run production in.
Bill Gunshannon
2017-12-07 15:58:00 UTC
Permalink
Post by Paul Sture
Timezones are constant and well defined.
Better than the DST mess, certainly, but not the whole story.
I did mention national boundaries changing.
"Falsehoods programmers believe about time"
<FalsehoodsAboutTime.com>
Except in the third world national boundaries really don't
change all that often. And, changing a national boundary
is unlikely to change the timezone the country is located
in. Unless the boundary change is the result of something
like a shift in tectonic plates. :-)

DST on the other hand is a political whim with no real
value.

bill
Michael Moroney
2017-12-07 19:12:46 UTC
Permalink
Post by Bill Gunshannon
Except in the third world national boundaries really don't
change all that often. And, changing a national boundary
is unlikely to change the timezone the country is located
in. Unless the boundary change is the result of something
like a shift in tectonic plates. :-)
DST on the other hand is a political whim with no real
value.
Any country or subdivision thereof can change the timezone it is in,
or go on or off summer time.

Massachusetts is toying with going into the Atlantic Time Zone year
round/year round DST (same thing).

North Korea changed the time zone it is in, around two years or so ago.
(and VSI added that to VMS, for our North Korean customers :-) )
Bill Gunshannon
2017-12-07 19:43:11 UTC
Permalink
Post by Michael Moroney
Post by Bill Gunshannon
Except in the third world national boundaries really don't
change all that often. And, changing a national boundary
is unlikely to change the timezone the country is located
in. Unless the boundary change is the result of something
like a shift in tectonic plates. :-)
DST on the other hand is a political whim with no real
value.
Any country or subdivision thereof can change the timezone it is in,
or go on or off summer time.
Yes, they can, but how many do it how often? How many ties have the DST
rules in the US changed during my working life?
Post by Michael Moroney
Massachusetts is toying with going into the Atlantic Time Zone year
round/year round DST (same thing).
And a number of west coast states wanted to stop the DST nonsense.
Somebody or something stopped them from doing it. I expect the same
would be the case with Massachusetts.
Post by Michael Moroney
North Korea changed the time zone it is in, around two years or so ago.
(and VSI added that to VMS, for our North Korean customers :-) )
Nothing North Korea does makes any sense. When your led by a madman
or an idiot (take your pick) strange things happen. The rest of
the world (including VSI) should just ignore him.

bill
Michael Moroney
2017-12-07 22:23:52 UTC
Permalink
Post by Bill Gunshannon
Post by Michael Moroney
Post by Bill Gunshannon
Except in the third world national boundaries really don't
change all that often. And, changing a national boundary
is unlikely to change the timezone the country is located
in. Unless the boundary change is the result of something
like a shift in tectonic plates. :-)
DST on the other hand is a political whim with no real
value.
Any country or subdivision thereof can change the timezone it is in,
or go on or off summer time.
Yes, they can, but how many do it how often? How many ties have the DST
rules in the US changed during my working life?
You may want to look at this, the database used by several OS's (including
VMS) to determine timezones. It contains all the changes often back to the
1800s or when they stopped using local solar time.
http://web.cs.ucla.edu/~eggert/tz/tz-link.htm
Post by Bill Gunshannon
Post by Michael Moroney
Massachusetts is toying with going into the Atlantic Time Zone year
round/year round DST (same thing).
And a number of west coast states wanted to stop the DST nonsense.
Somebody or something stopped them from doing it. I expect the same
would be the case with Massachusetts.
Last I heard, Mass. still wants to do this, but the idea is on hold until
if/when other New England states are willing to go along. I wouldn't mind
so much, getting dark shortly after 4PM is a bit depressing.
Post by Bill Gunshannon
Post by Michael Moroney
North Korea changed the time zone it is in, around two years or so ago.
(and VSI added that to VMS, for our North Korean customers :-) )
Nothing North Korea does makes any sense. When your led by a madman
or an idiot (take your pick) strange things happen. The rest of
the world (including VSI) should just ignore him.
Kind of hard to ignore a nut with nukes who keeps sabre-rattling by firing
off all those missiles.
Bill Gunshannon
2017-12-08 00:10:19 UTC
Permalink
Post by Michael Moroney
Post by Bill Gunshannon
Post by Michael Moroney
Post by Bill Gunshannon
Except in the third world national boundaries really don't
change all that often. And, changing a national boundary
is unlikely to change the timezone the country is located
in. Unless the boundary change is the result of something
like a shift in tectonic plates. :-)
DST on the other hand is a political whim with no real
value.
Any country or subdivision thereof can change the timezone it is in,
or go on or off summer time.
Yes, they can, but how many do it how often? How many ties have the DST
rules in the US changed during my working life?
You may want to look at this, the database used by several OS's (including
VMS) to determine timezones. It contains all the changes often back to the
1800s or when they stopped using local solar time.
http://web.cs.ucla.edu/~eggert/tz/tz-link.htm
Post by Bill Gunshannon
Post by Michael Moroney
Massachusetts is toying with going into the Atlantic Time Zone year
round/year round DST (same thing).
And a number of west coast states wanted to stop the DST nonsense.
Somebody or something stopped them from doing it. I expect the same
would be the case with Massachusetts.
Last I heard, Mass. still wants to do this, but the idea is on hold until
if/when other New England states are willing to go along. I wouldn't mind
so much, getting dark shortly after 4PM is a bit depressing.
See, that was what I meant. This is not something that would affect
only the state doing it.
Post by Michael Moroney
Post by Bill Gunshannon
Post by Michael Moroney
North Korea changed the time zone it is in, around two years or so ago.
(and VSI added that to VMS, for our North Korean customers :-) )
Nothing North Korea does makes any sense. When your led by a madman
or an idiot (take your pick) strange things happen. The rest of
the world (including VSI) should just ignore him.
Kind of hard to ignore a nut with nukes who keeps sabre-rattling by firing
off all those missiles.
I have felt all along that the missiles should have been shot
down as soon as they left North Korean airspace.

bill
Paul Sture
2017-12-08 19:34:03 UTC
Permalink
Post by Bill Gunshannon
Post by Michael Moroney
North Korea changed the time zone it is in, around two years or so ago.
(and VSI added that to VMS, for our North Korean customers :-) )
Nothing North Korea does makes any sense. When your led by a madman
or an idiot (take your pick) strange things happen. The rest of
the world (including VSI) should just ignore him.
No. If he says he's going to lob some rockets at midnight, we are
better off knowing when his midnight is.
--
Everybody has a testing environment. Some people are lucky enough to
have a totally separate environment to run production in.
David Froble
2017-12-09 04:28:59 UTC
Permalink
Post by Paul Sture
Post by Bill Gunshannon
Post by Michael Moroney
North Korea changed the time zone it is in, around two years or so ago.
(and VSI added that to VMS, for our North Korean customers :-) )
Nothing North Korea does makes any sense. When your led by a madman
or an idiot (take your pick) strange things happen. The rest of
the world (including VSI) should just ignore him.
No. If he says he's going to lob some rockets at midnight, we are
better off knowing when his midnight is.
Yeah, so we can lob many more an hour earlier ...

:-)
Paul Sture
2017-12-09 06:50:39 UTC
Permalink
Post by David Froble
Post by Paul Sture
Post by Bill Gunshannon
Post by Michael Moroney
North Korea changed the time zone it is in, around two years or so ago.
(and VSI added that to VMS, for our North Korean customers :-) )
Nothing North Korea does makes any sense. When your led by a madman
or an idiot (take your pick) strange things happen. The rest of
the world (including VSI) should just ignore him.
No. If he says he's going to lob some rockets at midnight, we are
better off knowing when his midnight is.
Yeah, so we can lob many more an hour earlier ...
:-)
Ooops.. I didn't mean that (~:
--
Everybody has a testing environment. Some people are lucky enough to
have a totally separate environment to run production in.
Stephen Hoffman
2017-12-10 01:32:42 UTC
Permalink
Post by David Froble
Post by Paul Sture
Post by Michael Moroney
North Korea changed the time zone it is in, around two years or so ago.
(and VSI added that to VMS, for our North Korean customers :-) )
Nothing North Korea does makes any sense. When your led by a madman or
an idiot (take your pick) strange things happen. The rest of the world
(including VSI) should just ignore him.
No. If he says he's going to lob some rockets at midnight, we are
better off knowing when his midnight is.
Yeah, so we can lob many more an hour earlier ...
:-)
https://www.washingtonpost.com/outlook/this-is-how-nuclear-war-with-north-korea-would-unfold/2017/12/08/4e298a28-db07-11e7-a841-2066faf731ef_story.html


OpenVMS will hopefully eventually allow new timezone definitions to be
downloaded from VSI or from the canonical source, either on explicit
system management command or automatically and on a schedule or with
notifications pushed from VSI. Timezone database updates, without
requiring the creation and distribution of patch kits. It's not like
the timezone data is forever unchanging.
--
Pure Personal Opinion | HoffmanLabs LLC
Simon Clubley
2017-12-08 14:25:56 UTC
Permalink
Post by Michael Moroney
North Korea changed the time zone it is in, around two years or so ago.
(and VSI added that to VMS, for our North Korean customers :-) )
Yes, I can see it now: pictures of a certain supreme leader displayed
on the streets of Pyongyang with the words "VMS is the best OS" written
underneath. :-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Jan-Erik Soderholm
2017-12-06 21:25:27 UTC
Permalink
Post by Paul Sture
<snip>
Post by Jan-Erik Soderholm
Post by Simon Clubley
This means that if you are in the US and submit a job to run
two hours from now then that is what will show up in "show queue".
If someone in Japan looks at the same job, the display should
show the release time in terms of Japanese local time so the
person in Japan will see a local release time that is also
two hours from now.
And then, in between, the US switch to DST.
Should the job stay on the same US-local time (now a different
UTC time, and showing a different time for the Japan user)?
Or should it stay on the same UTC time (and showing a different
time for the original US submitter, but same for the Japan user)?
The calculation should work out what the UTC time will be after
the DST change, and store that.
That is fine if you expect all users and the whole system to
live in a single TZ.

And what if one user living in an TZ *with* DST, submits a job
on behaf of (/user=xxx) a user that is living in a timezone that
does not have DST? How should the system know that?
Post by Paul Sture
If a job specifying "Monday at 3am" is submitted on the Friday before
the clocks change on Sunday morning, the system knows that the time
change will occur and calculate the appropriate UTC time to store in the
queue, so that the job will indeed run on Monday at 3am.
See comment above. Different user on th system can use, or might not
use, a TZ that uses DST. And even if they do, the DST cut-over dates
doesn't have to be the same. Should you enter each users TZ in the UAF?
Post by Paul Sture
Related is the problem of converting a historical set of dates and times
originally stored in local time to UTC. The DST offset at the given
date and time is taken into account and used in the conversion to UTV.
update some_table set utc_datetime = substr(datetime, 1, 10)|| ' ' ||
substr(datetime, 12,2) || ':' || substr(datetime, 14,2) || ':' ||
substr(datetime, 16,2) || ' Europe/Zurich';
But that only uses the DST rules (the cut-over dates and so on) that are
relevant today, doesn't it? Or does it contain historical tables with all
the old DST rules? The cut-over dates has changes and also the actual DST
time difference.

Just asking... :-)
Post by Paul Sture
There's probably a more elegant way of doing that, but it worked for
the task I had at the time.
Paul Sture
2017-12-06 22:07:03 UTC
Permalink
Post by Jan-Erik Soderholm
Post by Paul Sture
<snip>
Post by Jan-Erik Soderholm
Post by Simon Clubley
This means that if you are in the US and submit a job to run
two hours from now then that is what will show up in "show queue".
If someone in Japan looks at the same job, the display should
show the release time in terms of Japanese local time so the
person in Japan will see a local release time that is also
two hours from now.
And then, in between, the US switch to DST.
Should the job stay on the same US-local time (now a different
UTC time, and showing a different time for the Japan user)?
Or should it stay on the same UTC time (and showing a different
time for the original US submitter, but same for the Japan user)?
The calculation should work out what the UTC time will be after
the DST change, and store that.
That is fine if you expect all users and the whole system to
live in a single TZ.
And what if one user living in an TZ *with* DST, submits a job
on behaf of (/user=xxx) a user that is living in a timezone that
does not have DST? How should the system know that?
Good question.
Post by Jan-Erik Soderholm
Post by Paul Sture
If a job specifying "Monday at 3am" is submitted on the Friday before
the clocks change on Sunday morning, the system knows that the time
change will occur and calculate the appropriate UTC time to store in the
queue, so that the job will indeed run on Monday at 3am.
See comment above. Different user on th system can use, or might not
use, a TZ that uses DST. And even if they do, the DST cut-over dates
doesn't have to be the same. Should you enter each users TZ in the UAF?
Storing the user's TZ in the UAF would be more logical than relying on
a line in LOGIN.COM (or SYLOGIN, or a group login...).
Post by Jan-Erik Soderholm
Post by Paul Sture
Related is the problem of converting a historical set of dates and times
originally stored in local time to UTC. The DST offset at the given
date and time is taken into account and used in the conversion to UTV.
update some_table set utc_datetime = substr(datetime, 1, 10)|| ' ' ||
substr(datetime, 12,2) || ':' || substr(datetime, 14,2) || ':' ||
substr(datetime, 16,2) || ' Europe/Zurich';
But that only uses the DST rules (the cut-over dates and so on) that are
relevant today, doesn't it? Or does it contain historical tables with all
the old DST rules? The cut-over dates has changes and also the actual DST
time difference.
Just asking... :-)
Yes, the historical values are maintained. You really need to include
the timezone rather than the UTC offset to get the correct historical
information (which is why I used 'Europe/Zurich' in my example).

Just for fun, national boundary changes could come into this :-)

References:

IANA Time Zone Database

<https://www.iana.org/time-zones>

Chaos feared after Unix time-zone database is nuked (Oct 2011)
= Developer sued for copyright infringement

<https://www.theregister.co.uk/2011/10/07/unix_time_zone_database_destroyed/>

A literary appreciation of the Olson/Zoneinfo/tz database, which includes
some interesting historical snippets:

<https://blog.jonudell.net/2009/10/23/a-literary-appreciation-of-the-olsonzoneinfotz-database/>
--
Everybody has a testing environment. Some people are lucky enough to
have a totally separate environment to run production in.
Stephen Hoffman
2017-12-06 22:48:47 UTC
Permalink
Post by Paul Sture
Storing the user's TZ in the UAF would be more logical than relying on
a line in LOGIN.COM (or SYLOGIN, or a group login...).
Timezones aren't (usually) associated with specific users, they're
associated with physical locations; the location of the computer that
the user is logging into. Unfortunately, OpenVMS has no idea how to
determine that yet and no idea what to do with the user or computer
location if it did, though. Which means its on the individual
processes, and default values from either the server-wide configuration
or the local user's local configuration. Which means it'd be really
nice to add this into LDAP for the computer record and then (maybe,
where needed) add an override into the user record, rather continuing
to futz around with SYSUAF and all its warts and all its limitations
and its ever-fun-worthy upgrade-related hassles.

related:
http://www.alexandreviot.net/2017/02/08/windows-10-enable-automatic-timezone/

macOS and other systems can determine the timezone as part of the
default configuration; System Preferences > TimeZone, Set time zone
automatically using current location
Also see RFC 4833, for those systems that support retrieving the
timezone via the local DHCP server. https://tools.ietf.org/html/rfc4833

If using ssh, it's entirely possible to use SendEnv and AcceptEnv to
pass over whatever the client is configured for, including passing the
value of TZ from the ssh client to the ssh server. It'd be nice if
OpenVMS did that among OpenVMS clients, if that's not feasible in
general. ssh on OpenVMS does needs some help in other ways too, such
as the current lack of two-factor authentication (2FA) support; U2F
token or otherwise.

But then I'd expect to still see us setting the timezone per process
using system-wide settings and LOGIN.COM or SYLOGIN.COM and the
traditional logical name hackery for the foreseeable future.
--
Pure Personal Opinion | HoffmanLabs LLC
Simon Clubley
2017-12-07 13:50:40 UTC
Permalink
Post by Paul Sture
Post by Jan-Erik Soderholm
Post by Paul Sture
The calculation should work out what the UTC time will be after
the DST change, and store that.
That is fine if you expect all users and the whole system to
live in a single TZ.
And what if one user living in an TZ *with* DST, submits a job
on behaf of (/user=xxx) a user that is living in a timezone that
does not have DST? How should the system know that?
Good question.
In most cases it simply doesn't matter (and the system cannot know
the submitter's intentions because the submitter may have already
temporarily set the local timezone in their process to that of the
person in the /user qualifier as part of some other work.)

A submit/after will by default use the local timezone of the process
executing the submit command (after making any DST alterations as
required if the date crosses a DST boundary) and then convert the
time to GMT/UTC. That is the time the job will run at as the queue
manager will be running on GMT/UTC time internally.

If the submitter wants the job to run at a specific time in a specific
timezone then you simply specify that timezone during the submit:

$ submit test.com/after="20-dec-2017 13:13 EST"

IOW, the timezone is added to the date and time string and used when
converting the date/time to GMT/UTC time for storing in the queue manager.

Implying that you are using the timezone of the current process by
default is no different to how the current date is implied now when
you don't specify it.

Like I said, this is all really clean and elegant when you think about it.

Simon.

PS: BTW, as Stephen says, the same username can be in different timezones
at different times so putting it in the UAF may not be sufficient
unless there's a way for a non-privileged user to update that setting.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
V***@SendSpamHere.ORG
2017-12-06 18:57:34 UTC
Permalink
Post by j***@yahoo.co.uk
Post by Jan-Erik Soderholm
Post by John Reagan
Post by Jan-Erik Soderholm
Post by Simon Clubley
No, it's the time in the local timezone with the local timezone code
or offset appended. Try doing an "ls -l" and then an "ls -l --full"
on Linux to see an example.
Show me an example instead. I have never used a Linux system.
-rw-rw-r--. 1 jreagan jreagan 0 Dec 6 10:35 aaa.c
-rw-rw-r--. 1 jreagan jreagan 0 2017-12-06 10:35:06.288062491 -0500 aaa.c
-rw-rw-r--. 1 jreagan jreagan 0 Dec 6 07:35 aaa.c
-rw-rw-r--. 1 jreagan jreagan 0 2017-12-06 07:35:06.288062491 -0800 aaa.c
OK, thanks. Not much of an /full output, is it? :-)
Anyway. So the diff against UTC is that -0500 or -0800. OK.
If someone else from another TZ would be logged in to the same
system, he would/could see another timestamp on the file. If
he used his own local TZ.
Fine then. I get it. I also see all implications with such things
like the quemgr and similar. Jobs on timed-release, when should they
be released. According to the UTC time or to the new local time?
The positive side is of course that the core time of the system
will always be moving "forward" at the same speed. And the "real"
timestamps recorded in the files also. But the displayed time
will still move according to the changes of DST, just as today
in VMS.
I do not see a major overhaul of this coming soon.
You get it. There's possibly even more, such as within
a cluster, various things (used to?) rely on nodes having
a reasonably consistent idea of what time it is. Does
that still feature in this kind of discussion? Don't
know.
Doing it all properly will need some thought, but even if
now isn't the right er time for VSI to do the job in full
(which it probably isn't) the x86 port might be an
opportunity to do a bit of research and planning and
discussion and maybe setting out some "reserved for future
expansion" stuff.
The displayed time format for any given application setup
can eventually become a customer/user choice, much as it
has been (to an extent) for ages courtesy of VMS
facilities provided by LIB$DT_FORMAT() and friends. See
e.g. VMS Programming Concepts manual, section titled
http://h41379.www4.hpe.com/doc/82final/5841/5841pro_077.html
Some of us still remember the exciting surprises that
can be had by running one OS and then a different one
on the same box, when the OSes in question interpret
the hardware ("TOY") clock in different ways.
Some of us are still having fun trying to sync files
between FAT32 and NTFS filesystems, which can be fun.
Lots of interesting things to think about.
I addressed all this TZ nonsense eons ago (pre-2000) with a product that was,
at the time, intended for testing Y2K issue. However, it's been used to keep
time on files and other places in VMS consistent (ie. UTC base). The product
allows users to specify their time zone and this product adds or subtracts a
bias from the VMS time. ANYTHING using a VMS system service to obtain time,
set a time (absolute or relative) or react at a time, will work as advertised.
There's only one way when/where this doesn't work and that's when/where code
is DIRECTLY getting the VMS time quadword from EXE$GQ_SYSTIME. My systems are
all storing/using UTC WRT EXE$GQ_SYSTIME, BTW.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
Simon Clubley
2017-12-06 19:25:50 UTC
Permalink
Post by V***@SendSpamHere.ORG
I addressed all this TZ nonsense eons ago (pre-2000) with a product that was,
at the time, intended for testing Y2K issue. However, it's been used to keep
time on files and other places in VMS consistent (ie. UTC base). The product
allows users to specify their time zone and this product adds or subtracts a
bias from the VMS time. ANYTHING using a VMS system service to obtain time,
set a time (absolute or relative) or react at a time, will work as advertised.
There's only one way when/where this doesn't work and that's when/where code
is DIRECTLY getting the VMS time quadword from EXE$GQ_SYSTIME. My systems are
all storing/using UTC WRT EXE$GQ_SYSTIME, BTW.
I can see a lot of potential in this approach but one problem I can
see is that I don't see how the timezone itself could be a part of
any date/time display field.

Also, using this product, how easy would it be to specify a job release
time in a submit command that was either a local time or a timezone
based time ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
V***@SendSpamHere.ORG
2017-12-07 15:03:50 UTC
Permalink
Post by Simon Clubley
Post by V***@SendSpamHere.ORG
I addressed all this TZ nonsense eons ago (pre-2000) with a product that was,
at the time, intended for testing Y2K issue. However, it's been used to keep
time on files and other places in VMS consistent (ie. UTC base). The product
allows users to specify their time zone and this product adds or subtracts a
bias from the VMS time. ANYTHING using a VMS system service to obtain time,
set a time (absolute or relative) or react at a time, will work as advertised.
There's only one way when/where this doesn't work and that's when/where code
is DIRECTLY getting the VMS time quadword from EXE$GQ_SYSTIME. My systems are
all storing/using UTC WRT EXE$GQ_SYSTIME, BTW.
I can see a lot of potential in this approach but one problem I can
see is that I don't see how the timezone itself could be a part of
any date/time display field.
Also, using this product, how easy would it be to specify a job release
time in a submit command that was either a local time or a timezone
based time ?
Simple. Like I said, ANY system service which uses time is handled. If you
have a release date specified as an absolute time in your locale, it is off-
set appropriately to a GMT time. Remember, the original intent of the code
was to test Y2K. BTW, mine is the only one that got ALL the services right.
DEComHPaq pushed something from some company called Cyrano; a total disaster
in proper feigned time services handling.

As for the TZ, that's a formatting issue. Would you like GMT, EST, PDT, etc.
or +/- xx00 [UTC]?
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
David Froble
2017-12-06 22:10:54 UTC
Permalink
Post by Jan-Erik Soderholm
Post by John Reagan
Post by Jan-Erik Soderholm
Post by Simon Clubley
No, it's the time in the local timezone with the local timezone code
or offset appended. Try doing an "ls -l" and then an "ls -l --full"
on Linux to see an example.
Show me an example instead. I have never used a Linux system.
-rw-rw-r--. 1 jreagan jreagan 0 Dec 6 10:35 aaa.c
-rw-rw-r--. 1 jreagan jreagan 0 2017-12-06 10:35:06.288062491 -0500 aaa.c
-rw-rw-r--. 1 jreagan jreagan 0 Dec 6 07:35 aaa.c
-rw-rw-r--. 1 jreagan jreagan 0 2017-12-06 07:35:06.288062491 -0800 aaa.c
OK, thanks. Not much of an /full output, is it? :-)
Anyway. So the diff against UTC is that -0500 or -0800. OK.
If someone else from another TZ would be logged in to the same
system, he would/could see another timestamp on the file. If
he used his own local TZ.
Fine then. I get it. I also see all implications with such things
like the quemgr and similar. Jobs on timed-release, when should they
be released. According to the UTC time or to the new local time?
The positive side is of course that the core time of the system
will always be moving "forward" at the same speed. And the "real"
timestamps recorded in the files also. But the displayed time
will still move according to the changes of DST, just as today
in VMS.
I do not see a major overhaul of this coming soon.
Ayep! And then there is all the applications that use their own constructs for
date and time.

:-)
Paul Sture
2017-12-06 18:42:55 UTC
Permalink
Post by Jan-Erik Soderholm
Post by Simon Clubley
Post by Jan-Erik Soderholm
And the output from DIR /SINCE or /BEFORE using a specific timestamp
could be different for different users on the same system? That is,
if they are in different timezones. That is, if they specify the
same absolute time in the DIR command, they would/could get
different output?
Yes. However, don't think of it as an absolute time. Think of it as
the local time in the location that the person is entering the command.
OK. So if one user sees something weird, and mails his output, including
the DIR command used, the other used cannot reproduce the output using
the same DIR command without fiddling with timezones, right?
It depends on the application doing the display, in this case DIR.
This isn't any different from what users in different time zones
will see if their systems only understand local time.
Post by Jan-Erik Soderholm
Post by Simon Clubley
Post by Jan-Erik Soderholm
Or would the display always be UTC with a timezone code appended?
No, it's the time in the local timezone with the local timezone code
or offset appended. Try doing an "ls -l" and then an "ls -l --full"
on Linux to see an example.
Show me an example instead. I have never used a Linux system.
On a Unix system (a descendant of Solaris), with the time set to UTC:

(the 'og' in the 'ls' commands below excludes ownership details, for
brevity. '# ' is the prompt)

# date
6 December 2017 at 18:38:44 UTC
# ls -log
total 20
-rw------- 1 2808 Nov 29 07:27 authorized_keys
-rw------- 1 1675 Nov 29 07:27 id_rsa
-rw------- 1 393 Nov 29 07:27 id_rsa.pub
-rw------- 1 3105 Nov 29 07:27 known_hosts

# ls -log --full
total 20
-rw------- 1 2808 2017-11-29 08:27:59.256190000 +0100 authorized_keys
-rw------- 1 1675 2017-11-29 08:27:59.288237000 +0100 id_rsa
-rw------- 1 393 2017-11-29 08:27:59.291976000 +0100 id_rsa.pub
-rw------- 1 3105 2017-11-29 08:27:59.284669000 +0100 known_hosts

That last display again, but displaying the times in my local timezone:

# TZ="Europe/Zurich" ls -log --full
total 20
-rw------- 1 2808 2017-11-29 08:27:59.256190000 +0100 authorized_keys
-rw------- 1 1675 2017-11-29 08:27:59.288237000 +0100 id_rsa
-rw------- 1 393 2017-11-29 08:27:59.291976000 +0100 id_rsa.pub
-rw------- 1 3105 2017-11-29 08:27:59.284669000 +0100 known_hosts

The output of the 'date' command can be altered in the same way, prepending
the command with setting the TZ environment variable to something else:

# date
6 December 2017 at 18:41:52 UTC
# TZ="Europe/Zurich" date
6 December 2017 at 19:42:00 CET
# TZ="Europe/Athens" date
6 December 2017 at 20:42:04 EET
--
Everybody has a testing environment. Some people are lucky enough to
have a totally separate environment to run production in.
David Froble
2017-12-06 22:07:34 UTC
Permalink
Post by Jan-Erik Soderholm
Post by Simon Clubley
Post by David Froble
Post by Simon Clubley
The filesystem is only part of it; all the other date/time code would
probably need to be touched as well.
It also has some other implications as well. For example, if you allow
per process timezones, do you now need to display timestamps with
a timezone suffix added (just like you do on Unix) ?
I don't see why it could not be an option.
And then the question will come up, what happens in a cluster ...
That's the beauty of this - it should make absolutely no difference
in a cluster at all.
You could have different nodes of a cluster in different timezones,
with each node set to the timezone for its location and then you could
have a user logging in from yet another timezone with the process
specific timezone set to the user's location.
The reason why all this just works is because they would all be using
the same time (GMT/UTC). In a proper GMT/UTC system (such as that
implemented on Unix), the timezone specific time is just a view into
the GMT/UTC base time.
BTW, I wonder what the record is for the number of different timezones
that the nodes of a share-everything VMScluster occupies.
Simon.
So two users in two different timezones doing a DIR on the *same
file(s)* would see different timestamp(s) on the files?
Well, the UTC time would be the "absolute" time. However, consider, I'm
assuming that you're UTC +2, and I'm UTC -4. So 6 time zones apart. You create
a file (or do something) at 12 noon your time. That's 6:00 AM my time. If I
look at the time on the file (or object) at 10:00 AM my time, I'd see that it
had a time stamp of 6:00 AM, my local time.

I'd really rather not see the time stamp 2 hours into the future, if your time
of 12 noon was displayed to me.

Not different timestamps. I'd assume one could choose their local time, or UTC
time, and get the correct time displayed.

Now, it'd be rather simple to allow one to ask to see the time stamp for time
zone "X", though, right now I don't see any use for such. I'm sure someone
somewhere might have such use.
Post by Jan-Erik Soderholm
And the output from DIR /SINCE or /BEFORE using a specific timestamp
could be different for different users on the same system? That is,
if they are in different timezones. That is, if they specify the
same absolute time in the DIR command, they would/could get
different output?
If you're operating in your local time zone, then all times would be in that
time zone. Thus the /SINCE and /BEFORE and such would look at all times in the
perspective of your time zone.

And now, already, I see a use for specifying a time zone. Suppose you wanted to
see all files created between 6:00 AM and 8:00 AM, in Hong Kong. Perhaps you
could add the time zone to the DIR command.
Dirk Munk
2017-12-08 01:34:34 UTC
Permalink
Post by Simon Clubley
Post by David Froble
Post by Simon Clubley
The filesystem is only part of it; all the other date/time code would
probably need to be touched as well.
It also has some other implications as well. For example, if you allow
per process timezones, do you now need to display timestamps with
a timezone suffix added (just like you do on Unix) ?
I don't see why it could not be an option.
And then the question will come up, what happens in a cluster ...
That's the beauty of this - it should make absolutely no difference
in a cluster at all.
Cluster nodes should always have the same time. In DECnet Phase V DTSS
was used to accomplish this, and it used UTC. Alternatively you can use
NTP, which also uses UTC.
Post by Simon Clubley
You could have different nodes of a cluster in different timezones,
with each node set to the timezone for its location and then you could
have a user logging in from yet another timezone with the process
specific timezone set to the user's location.
The reason why all this just works is because they would all be using
the same time (GMT/UTC). In a proper GMT/UTC system (such as that
implemented on Unix), the timezone specific time is just a view into
the GMT/UTC base time.
BTW, I wonder what the record is for the number of different timezones
that the nodes of a share-everything VMScluster occupies.
Simon.
Simon Clubley
2017-12-08 14:31:24 UTC
Permalink
Post by Dirk Munk
Post by Simon Clubley
That's the beauty of this - it should make absolutely no difference
in a cluster at all.
Cluster nodes should always have the same time. In DECnet Phase V DTSS
was used to accomplish this, and it used UTC. Alternatively you can use
NTP, which also uses UTC.
And they would continue to do so. It's just the localised view into the
GMT/UTC system time that would change depending which timezone each
cluster node is in.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Dirk Munk
2017-12-08 16:48:54 UTC
Permalink
Post by Simon Clubley
Post by Dirk Munk
Post by Simon Clubley
That's the beauty of this - it should make absolutely no difference
in a cluster at all.
Cluster nodes should always have the same time. In DECnet Phase V DTSS
was used to accomplish this, and it used UTC. Alternatively you can use
NTP, which also uses UTC.
And they would continue to do so. It's just the localised view into the
GMT/UTC system time that would change depending which timezone each
cluster node is in.
Simon.
Exactly.
David Froble
2017-12-09 04:32:53 UTC
Permalink
Post by Dirk Munk
Post by Simon Clubley
Post by Dirk Munk
Post by Simon Clubley
That's the beauty of this - it should make absolutely no difference
in a cluster at all.
Cluster nodes should always have the same time. In DECnet Phase V DTSS
was used to accomplish this, and it used UTC. Alternatively you can use
NTP, which also uses UTC.
And they would continue to do so. It's just the localised view into the
GMT/UTC system time that would change depending which timezone each
cluster node is in.
Simon.
Exactly.
Are we talking just x86 nodes in a cluster, or, are we talking VAX, Alpha,
itanic, and x86 nodes in a cluster? Somehow I've got to believe it's an all or
nothing thing.
Simon Clubley
2017-12-09 12:11:00 UTC
Permalink
Post by David Froble
Are we talking just x86 nodes in a cluster, or, are we talking VAX, Alpha,
itanic, and x86 nodes in a cluster? Somehow I've got to believe it's an all or
nothing thing.
It is. It would require _all_ nodes in the cluster to have a sane
timezone implementation unfortunately.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Dirk Munk
2017-12-11 02:07:40 UTC
Permalink
Post by Simon Clubley
Post by David Froble
Are we talking just x86 nodes in a cluster, or, are we talking VAX, Alpha,
itanic, and x86 nodes in a cluster? Somehow I've got to believe it's an all or
nothing thing.
It is. It would require _all_ nodes in the cluster to have a sane
timezone implementation unfortunately.
Simon.
No of course not. DTSS and NTP use UTC, so it doesn't matter in which
time zone a cluster node is located. So at present two cluster nodes can
be in two different time zones, they compare their clocks based on UTC.
Stephen Hoffman
2017-12-06 20:51:04 UTC
Permalink
Post by David Froble
Post by Simon Clubley
Post by Dirk Munk
DECnet Phase V / OSI has always been using UTC timestamps. I see no
reason why it could not be implemented in a file system as well.
The filesystem is only part of it; all the other date/time code would
probably need to be touched as well.
It also has some other implications as well. For example, if you allow
per process timezones, do you now need to display timestamps with a
timezone suffix added (just like you do on Unix) ?
Simon.
I don't see why it could not be an option.
And then the question will come up, what happens in a cluster ...
And in the background we hear Steve chanting "bust it", "bust it" ...
:-)
So long as that doesn't introduce a new forest of configuration logical
names or other such dreck, yes, provide a migration path to get out of
the current timekeeping hole.

But for VAFS specifically and prior to the arrival of the necessary
truckloads of schedule time and staff, this can be handled entirely
within VAFS, assigning UTC to objects and returning localtime to
existing APIs.

Or VAFS can be ignored, since it's no different than where things are
with ODS volumes.

Any VSI project intended to migrate those will have to adjust every
blasted timestamp, or will more likely be left to document that the
times will be off by a day or so at most. This once (if) VSI designs
and publishes and ships a bull and a project akin to Inter gravissimas.
And I don't see this remediation work being anywhere near the top of
the VSI schedule. Never has been. There's precedent for these
transitions getting dragged out, though. Inter gravissimas lasted
from 1582 into the twentieth century, after all.
--
Pure Personal Opinion | HoffmanLabs LLC
Bob Koehler
2017-12-06 16:24:50 UTC
Permalink
Post by Dirk Munk
DECnet Phase V / OSI has always been using UTC timestamps. I see no
reason why it could not be implemented in a file system as well.
I beieve that's part of the ISO/OSI newtork standard, and to do OSI
networking there's no choice.

To do it to the file system could mean massive breakage. All of
which could be fixed with time and money.

Will you front the money?
Dirk Munk
2017-12-08 01:28:00 UTC
Permalink
Post by Bob Koehler
Post by Dirk Munk
DECnet Phase V / OSI has always been using UTC timestamps. I see no
reason why it could not be implemented in a file system as well.
I beieve that's part of the ISO/OSI newtork standard, and to do OSI
networking there's no choice.
To do it to the file system could mean massive breakage. All of
which could be fixed with time and money.
Will you front the money?
The fact that VMS was set up using the local time was a monumental
stupidity. The whole world is using UTC as the timebase. UTC is
available in VMS, and it should be used in a new file system.  If you
want to make it visible in which timezone the file was made, I don't care.

Look what happens now when time changes from summertime to wintertime.
The clock goes back from 03:00 to 02:00 hours, so the hour from 02:00 to
03:00 hrs. happens twice!!  If two files have been made, one at 02:15
and one at 02:30, which one was made first?? It is impossible to know.
And what about timestamps in databases based on local time? The same
problem.

UTC stands for Universal Time Coordinate, the name should give away why
it should be used.
Stephen Hoffman
2017-12-06 18:50:57 UTC
Permalink
Post by Michael Moroney
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 local offset.
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.
There ain't no "become part of a crazy quilt". The whole timekeeping
implementation is a flaming dumpster fire, long overdue for nuking and
paving. There've been more than a few cases adding a few more logical
names and a few more hacks, with most folks looking at the problem and
deciding to run far, far, far, far, far, far, far away. For reasons
of compatibility, and of the ever-popular "we have other intractable
messes to wrangle", and "we need to add these other features for more
immediate revenues", of course.

The new file system can write the UTC dates onto the disk and avoid
some of the existing mess, assuming that the new file system design
(somewhat surprisingly) lacks support for attaching the UTC. This
involves the system-wide time and (initially) the system-wide TDF value
from EXE$GQ_TDF, and some not-college-level math. This in isolation
from the rest of the OpenVMS timekeeping morass and the rest of the I/O
and API stacks, save for skewing time values between UTC time and local
time on read and write paths involving the time values, (temporarily)
right within the file system layer. Nothing higher would encounter
UTC, at least for now. This makes one less spot where local time is
attached to an object. Not that there's any shortage of those local
time values persistently and ubiquitously attached all around the
objects of the OpenVMS universe, so... what's one more?
--
Pure Personal Opinion | HoffmanLabs LLC
m***@gmail.com
2017-12-10 00:48:33 UTC
Permalink
Post by Simon Clubley
[This is just something that occurred to me while looking at something
else. I don't recall seeing this discussed so apologies if it has been.]
Will the new VMS filesystem use the local system time on its timestamps
or will it use GMT and then convert to local time from there ?
If it does use the local system time, will it also store away the
timezone offset active at the point the timestamp was created ?
In the latter case, this would be the current numeric offset (+0100 for
example) and not the actual timezone identifier such as BST/EST/etc.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world
I don't get it. What exactly is wrong with having a system time usually based on the location of the system? If you are accessing that system then the time is whatever it is local to that system. Sure there's an issue with network access and clusters split across time zones, but is it really a big issue when you can work with relative time (eg. +4:00)?

Time on early systems was not a big deal because users were local. Clusters and networks only appeared later, besides which CPU time (and memory) were expensive back in those days so developers didn't want to waste them.

Is it really worth the time and effort to change the whole time-handling system to satisfy what is likely to be some minority of users? Sure you can dream up instances where it might be useful but how many users would it be useful for?

And from the discussion here it's pretty obvious that you'd need utilities to go with any changes so that system managers and operators can see the time base that a given cluster member - or even user - is using at the time.

Time handling might be a bit of a can worms at the moment but where's the value in upgrading that a catering sized can?
Johnny Billquist
2017-12-10 11:14:47 UTC
Permalink
Post by m***@gmail.com
Post by Simon Clubley
[This is just something that occurred to me while looking at something
else. I don't recall seeing this discussed so apologies if it has been.]
Will the new VMS filesystem use the local system time on its timestamps
or will it use GMT and then convert to local time from there ?
If it does use the local system time, will it also store away the
timezone offset active at the point the timestamp was created ?
In the latter case, this would be the current numeric offset (+0100 for
example) and not the actual timezone identifier such as BST/EST/etc.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world
I don't get it. What exactly is wrong with having a system time usually based on the location of the system? If you are accessing that system then the time is whatever it is local to that system. Sure there's an issue with network access and clusters split across time zones, but is it really a big issue when you can work with relative time (eg. +4:00)?
Time on early systems was not a big deal because users were local. Clusters and networks only appeared later, besides which CPU time (and memory) were expensive back in those days so developers didn't want to waste them.
Is it really worth the time and effort to change the whole time-handling system to satisfy what is likely to be some minority of users? Sure you can dream up instances where it might be useful but how many users would it be useful for?
And from the discussion here it's pretty obvious that you'd need utilities to go with any changes so that system managers and operators can see the time base that a given cluster member - or even user - is using at the time.
Time handling might be a bit of a can worms at the moment but where's the value in upgrading that a catering sized can?
Well, as people have pointed out, timezones are not static. Many places
include DST in the whole time zone mess, which means that if you use
local time, then you need to update your local time twice a year, and
you get funny effect, such as files being created in the future, the
same time repeating twice, hours that does not exist, and god knows what
falls out from all that.
It is, for many, really ugly, and is why you hear of places that shuts
everything down at DST change, and wait for an hour before starting
things up again.

And once you start trying to fix the whole DST mess, you inevitably gets
into the full scope of time zones, since that is just a milder form of
the DST mess.

TZ does matter. If you sit on a system, and you want to submit a job to
run at 10AM, you normally mean 10AM your local time, which might be a
very different time than what the system thinks, if it is in a different
time zone. The same if you want to find files changed today. When
"today" is differs depending on which time zone you are in.

I could go on, but I hope you get the picture...

Johnny
--
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
Jan-Erik Soderholm
2017-12-10 11:37:16 UTC
Permalink
Post by Johnny Billquist
Post by Simon Clubley
[This is just something that occurred to me while looking at something
else. I don't recall seeing this discussed so apologies if it has been.]
Will the new VMS filesystem use the local system time on its timestamps
or will it use GMT and then convert to local time from there ?
If it does use the local system time, will it also store away the
timezone offset active at the point the timestamp was created ?
In the latter case, this would be the current numeric offset (+0100 for
example) and not the actual timezone identifier such as BST/EST/etc.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world
I don't get it.  What exactly is wrong with having a system time usually
based on the location of the system?  If you are accessing that system
then the time is whatever it is local to that system. Sure there's an
issue with network access and clusters split across time zones, but is it
really a big issue when you can work with relative time (eg. +4:00)?
Time on early systems was not a big deal because users were local.
Clusters and networks only appeared later, besides which CPU time (and
memory) were expensive back in those days so developers didn't want to
waste them.
Is it really worth the time and effort to change the whole time-handling
system to satisfy what is likely to be some minority of users?  Sure you
can dream up instances where it might be useful but how many users would
it be useful for?
And from the discussion here it's pretty obvious that you'd need
utilities to go with any changes so that system managers and operators
can see the time base that a given cluster member - or even user - is
using at the time.
Time handling might be a bit of a can worms at the moment but where's the
value in upgrading that a catering sized can?
Well, as people have pointed out, timezones are not static. Many places
include DST in the whole time zone mess, which means that if you use local
time, then you need to update your local time twice a year, and you get
funny effect, such as files being created in the future, the same time
repeating twice, hours that does not exist, and god knows what falls out
from all that.
Now, if you (only) use UTC internally, and still display everyting in
local time, would anything change in this regard? The local time will
still "jump" at the DST changes, not? And you are still supposed to
use local time in your /since and /before commands, not?

All the "funny effects" you mention above, will still be seen by a user.
Johnny Billquist
2017-12-10 12:18:52 UTC
Permalink
Post by Jan-Erik Soderholm
Post by Johnny Billquist
Post by Simon Clubley
[This is just something that occurred to me while looking at something
else. I don't recall seeing this discussed so apologies if it has been.]
Will the new VMS filesystem use the local system time on its timestamps
or will it use GMT and then convert to local time from there ?
If it does use the local system time, will it also store away the
timezone offset active at the point the timestamp was created ?
In the latter case, this would be the current numeric offset (+0100 for
example) and not the actual timezone identifier such as BST/EST/etc.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world
I don't get it.  What exactly is wrong with having a system time
usually based on the location of the system?  If you are accessing
that system then the time is whatever it is local to that system.
Sure there's an issue with network access and clusters split across
time zones, but is it really a big issue when you can work with
relative time (eg. +4:00)?
Time on early systems was not a big deal because users were local.
Clusters and networks only appeared later, besides which CPU time
(and memory) were expensive back in those days so developers didn't
want to waste them.
Is it really worth the time and effort to change the whole
time-handling system to satisfy what is likely to be some minority of
users?  Sure you can dream up instances where it might be useful but
how many users would it be useful for?
And from the discussion here it's pretty obvious that you'd need
utilities to go with any changes so that system managers and
operators can see the time base that a given cluster member - or even
user - is using at the time.
Time handling might be a bit of a can worms at the moment but where's
the value in upgrading that a catering sized can?
Well, as people have pointed out, timezones are not static. Many
places include DST in the whole time zone mess, which means that if
you use local time, then you need to update your local time twice a
year, and you get funny effect, such as files being created in the
future, the same time repeating twice, hours that does not exist, and
god knows what falls out from all that.
Now, if you (only) use UTC internally, and still display everyting in
local time, would anything change in this regard? The local time will
still "jump" at the DST changes, not? And you are still supposed to
use local time in your /since and /before commands, not?
All the "funny effects" you mention above, will still be seen by a user.
No. Because internally in the system, the time increases at a monotonic
rate if we use UTC all the time.
Internally, the system does not have the same time twice. You might see
the same time for two different UTC times, but that is because this is
the perceived correct presentation of the time. However, internally,
there can be no doubt that one thing happening 1h later than the
previous thing, really is just one 1h, no matter what time zone, or DST
adjustments.

So while you think things will look the same to the user, they will not,
but sometimes the difference is not obvious until you starting thinking
and looking a bit deeper. Take file timestamps, for example. Your
/since, might include one file, but exclude another even though they
display the same. Also, when you sort the files according to time, they
might show up in the "wrong" order, but which is actually correct. A
file stamped 02.35 might indeed come before a file stamped 02.30. No way
of figuring that out if you just stamp them with local time. However, if
they are stamped in UTC, it becomes unambiguous. When you ask for
sorting by time, you assume that the "older" file is shown before/after
the other file. And "older" is irrespective of DST. If the file a was
created before file b, it is older, even if the presented time, based on
some time zone and DST rules shows times that suggest the relationship
is the opposite.

Johnny
--
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
Jan-Erik Soderholm
2017-12-10 12:38:36 UTC
Permalink
Post by Johnny Billquist
Post by Jan-Erik Soderholm
Post by Johnny Billquist
Post by Simon Clubley
[This is just something that occurred to me while looking at something
else. I don't recall seeing this discussed so apologies if it has been.]
Will the new VMS filesystem use the local system time on its timestamps
or will it use GMT and then convert to local time from there ?
If it does use the local system time, will it also store away the
timezone offset active at the point the timestamp was created ?
In the latter case, this would be the current numeric offset (+0100 for
example) and not the actual timezone identifier such as BST/EST/etc.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world
I don't get it.  What exactly is wrong with having a system time
usually based on the location of the system?  If you are accessing that
system then the time is whatever it is local to that system. Sure
there's an issue with network access and clusters split across time
zones, but is it really a big issue when you can work with relative
time (eg. +4:00)?
Time on early systems was not a big deal because users were local.
Clusters and networks only appeared later, besides which CPU time (and
memory) were expensive back in those days so developers didn't want to
waste them.
Is it really worth the time and effort to change the whole
time-handling system to satisfy what is likely to be some minority of
users?  Sure you can dream up instances where it might be useful but
how many users would it be useful for?
And from the discussion here it's pretty obvious that you'd need
utilities to go with any changes so that system managers and operators
can see the time base that a given cluster member - or even user - is
using at the time.
Time handling might be a bit of a can worms at the moment but where's
the value in upgrading that a catering sized can?
Well, as people have pointed out, timezones are not static. Many places
include DST in the whole time zone mess, which means that if you use
local time, then you need to update your local time twice a year, and
you get funny effect, such as files being created in the future, the
same time repeating twice, hours that does not exist, and god knows what
falls out from all that.
Now, if you (only) use UTC internally, and still display everyting in
local time, would anything change in this regard? The local time will
still "jump" at the DST changes, not? And you are still supposed to
use local time in your /since and /before commands, not?
All the "funny effects" you mention above, will still be seen by a user.
No.
So the displayed time stamp will not be local time? That repeat itself
or sometimes lack a full hour?
Post by Johnny Billquist
Because internally in the system, the time increases at a monotonic
rate if we use UTC all the time.
Yes, but that is not obvious for the ordinary user, is it? And that
is not what is (ment to be) displayed in a DIR listing, is it?
Post by Johnny Billquist
Internally, the system does not have the same time twice. You might see the
same time for two different UTC times, but that is because this is the
perceived correct presentation of the time.
And also the time that the user sees, not?
Post by Johnny Billquist
However, internally, there can
be no doubt that one thing happening 1h later than the previous thing,
really is just one 1h, no matter what time zone, or DST adjustments.
And the user sees that, how? Will the internal UTC time be used
(Displayed) instead of the local time?
Post by Johnny Billquist
So while you think things will look the same to the user, they will not,
You just said above that they would.
Post by Johnny Billquist
but sometimes the difference is not obvious until you starting thinking and
looking a bit deeper.
And the user does that, how?
Post by Johnny Billquist
Take file timestamps, for example. Your /since, might
include one file, but exclude another even though they display the same.
And the user will not ask "why?"?
Post by Johnny Billquist
Also, when you sort the files according to time, they might show up in the
"wrong" order, but which is actually correct.
And perfectly logical order to the user?
Post by Johnny Billquist
A file stamped 02.35 might
indeed come before a file stamped 02.30. No way of figuring that out if you
just stamp them with local time. However, if they are stamped in UTC, it
becomes unambiguous. When you ask for sorting by time, you assume that the
"older" file is shown before/after the other file. And "older" is
irrespective of DST. If the file a was created before file b, it is older,
even if the presented time, based on some time zone and DST rules shows
times that suggest the relationship is the opposite.
Thay there might be some logic there. In particular if you are soring
files before some procesing. But for a ordinary user getting a file
list from DIR, it is still a bit confusing.

I understand the benefits internally to the system with UTC, but
it will not change a bit for an ordinary user.


Now, not that I expect that many, if any at all, ordinary users
that has DCL access to a VMS system... :-)

Jan-Erik.
Post by Johnny Billquist
  Johnny
Johnny Billquist
2017-12-10 12:57:04 UTC
Permalink
Post by Jan-Erik Soderholm
Post by Johnny Billquist
Post by Jan-Erik Soderholm
Post by Johnny Billquist
I don't get it.  What exactly is wrong with having a system time
usually based on the location of the system?  If you are accessing
that system then the time is whatever it is local to that system.
Sure there's an issue with network access and clusters split across
time zones, but is it really a big issue when you can work with
relative time (eg. +4:00)?
Time on early systems was not a big deal because users were local.
Clusters and networks only appeared later, besides which CPU time
(and memory) were expensive back in those days so developers didn't
want to waste them.
Is it really worth the time and effort to change the whole
time-handling system to satisfy what is likely to be some minority
of users?  Sure you can dream up instances where it might be useful
but how many users would it be useful for?
And from the discussion here it's pretty obvious that you'd need
utilities to go with any changes so that system managers and
operators can see the time base that a given cluster member - or
even user - is using at the time.
Time handling might be a bit of a can worms at the moment but
where's the value in upgrading that a catering sized can?
Well, as people have pointed out, timezones are not static. Many
places include DST in the whole time zone mess, which means that if
you use local time, then you need to update your local time twice a
year, and you get funny effect, such as files being created in the
future, the same time repeating twice, hours that does not exist,
and god knows what falls out from all that.
Now, if you (only) use UTC internally, and still display everyting in
local time, would anything change in this regard? The local time will
still "jump" at the DST changes, not? And you are still supposed to
use local time in your /since and /before commands, not?
All the "funny effects" you mention above, will still be seen by a user.
No.
So the displayed time stamp will not be local time? That repeat itself
or sometimes lack a full hour?
You asked if all the funny effects will be seen by users, and the answer
is no. You will not get all the funny effects. But you will still see
local times as a user, which means you will see two different time
stamps shown as the same by the user. But that is not "all", that is
just one detail. As I expanded on below, there are times and places
where there will be visible effects to the users.

Not to mention that there will be effects for programs and tools...
Post by Jan-Erik Soderholm
Post by Johnny Billquist
Because internally in the system, the time increases at a monotonic
rate if we use UTC all the time.
Yes, but that is not obvious for the ordinary user, is it? And that
is not what is (ment to be) displayed in a DIR listing, is it?
Why do you now focus on just one detail in one aspect, as if that would
be the only reason or cause for changing to UTC?
Post by Jan-Erik Soderholm
Post by Johnny Billquist
Internally, the system does not have the same time twice. You might
see the same time for two different UTC times, but that is because
this is the perceived correct presentation of the time.
And also the time that the user sees, not?
Post by Johnny Billquist
However, internally, there can be no doubt that one thing happening 1h
later than the previous thing, really is just one 1h, no matter what
time zone, or DST adjustments.
And the user sees that, how? Will the internal UTC time be used
(Displayed) instead of the local time?
See below, where I gave some examples of times when this makes a difference.
Post by Jan-Erik Soderholm
Post by Johnny Billquist
So while you think things will look the same to the user, they will not,
You just said above that they would.
Why did you not read the full text instead of picking select bits and
pieces and making arguments on those?
Anything, quoted out of context, can be made to mean almost anything.
Not meaningful.
Post by Jan-Erik Soderholm
Post by Johnny Billquist
but sometimes the difference is not obvious until you starting
thinking and looking a bit deeper.
And the user does that, how?
I explained that in the next few sentences. Why do you make such a silly
argument here?
Post by Jan-Erik Soderholm
Post by Johnny Billquist
Take file timestamps, for example. Your /since, might include one
file, but exclude another even though they display the same.
And the user will not ask "why?"?
People might always ask "why". What does have to do with this?
Post by Jan-Erik Soderholm
Post by Johnny Billquist
Also, when you sort the files according to time, they might show up in
the "wrong" order, but which is actually correct.
And perfectly logical order to the user?
I would say so, yes. I think it is wrong that an older file would be
sorted as more recent than a newer file.
If you think otherwise, you should probably start by explaining your
reasoning for that.
Post by Jan-Erik Soderholm
Post by Johnny Billquist
A file stamped 02.35 might indeed come before a file stamped 02.30. No
way of figuring that out if you just stamp them with local time.
However, if they are stamped in UTC, it becomes unambiguous. When you
ask for sorting by time, you assume that the "older" file is shown
before/after the other file. And "older" is irrespective of DST. If
the file a was created before file b, it is older, even if the
presented time, based on some time zone and DST rules shows times that
suggest the relationship is the opposite.
Thay there might be some logic there. In particular if you are soring
files before some procesing. But for a ordinary user getting a file
list from DIR, it is still a bit confusing.
I don't agree. If I ask for files to be sorted based on creation time, I
would expect that a file that was created before another file to also be
sorted in that order, and not some other strange order just because
there was a change in DST in between. The change in DST does not in fact
change in which order the files were created.
Post by Jan-Erik Soderholm
I understand the benefits internally to the system with UTC, but
it will not change a bit for an ordinary user.
Now, not that I expect that many, if any at all, ordinary users
that has DCL access to a VMS system... :-)
That, I guess, boils down more to having interactive access to systems
in general. A different question.

Johnny
--
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
Simon Clubley
2017-12-10 19:14:20 UTC
Permalink
Post by Jan-Erik Soderholm
So the displayed time stamp will not be local time? That repeat itself
or sometimes lack a full hour?
No, it is still local time. It's just that the local time is now on
the other side of a DST boundary. It becomes completely clear if you
display the timezone just as you can do on Linux with "ls -l --full".

In fact, if you can use the 3 letter timezone identifiers or the numeric
timezone offset instead of the full verbose timezone identifiers now
increasingly in use, then there are some commands where displaying the
timezone always would be a good idea.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Paul Sture
2017-12-10 12:48:38 UTC
Permalink
Post by Johnny Billquist
Post by Jan-Erik Soderholm
Now, if you (only) use UTC internally, and still display everyting in
local time, would anything change in this regard? The local time will
still "jump" at the DST changes, not? And you are still supposed to
use local time in your /since and /before commands, not?
All the "funny effects" you mention above, will still be seen by a user.
No. Because internally in the system, the time increases at a
monotonic rate if we use UTC all the time.
Internally, the system does not have the same time twice. You might
see the same time for two different UTC times, but that is because
this is the perceived correct presentation of the time. However,
internally, there can be no doubt that one thing happening 1h later
than the previous thing, really is just one 1h, no matter what time
zone, or DST adjustments.
Correct.
Post by Johnny Billquist
So while you think things will look the same to the user, they will
not, but sometimes the difference is not obvious until you starting
thinking and looking a bit deeper. Take file timestamps, for example.
Your /since, might include one file, but exclude another even though
they display the same. Also, when you sort the files according to
time, they might show up in the "wrong" order, but which is actually
correct. A file stamped 02.35 might indeed come before a file stamped
02.30. No way of figuring that out if you just stamp them with local
time. However, if they are stamped in UTC, it becomes unambiguous.
When you ask for sorting by time, you assume that the "older" file is
shown before/after the other file. And "older" is irrespective of DST.
If the file a was created before file b, it is older, even if the
presented time, based on some time zone and DST rules shows times that
suggest the relationship is the opposite.
It depends on the application implementation. Do /since and sort
operate on the UTC timestamp or the local time?

It might help to think of the output of a web form here, where clicking
on a title field sorts by that column. Unless both UTC and local times
are displayed, sorted by local time displays can look "wrong" for that
period of time when the clocks went back.

One idea I cam across recently was for user displays to mark times in
such a period (e.g. with '*') to show that they fall in such a window.
--
Everybody has a testing environment. Some people are lucky enough to
have a totally separate environment to run production in.
Simon Clubley
2017-12-10 19:20:44 UTC
Permalink
Post by Paul Sture
It depends on the application implementation. Do /since and sort
operate on the UTC timestamp or the local time?
It works on whatever is the timezone as the process currently sees it
unless a timezone is specified as part of the command.

This is exactly the same way as the current date is assumed unless
a date is specified as part of the command.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Simon Clubley
2017-12-10 19:17:11 UTC
Permalink
Post by Jan-Erik Soderholm
All the "funny effects" you mention above, will still be seen by a user.
No, they won't. For a really simple example, makefiles will still work
correctly if they are in use during a DST transition. Good luck with
trying to guarantee that at the moment. :-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Jan-Erik Soderholm
2017-12-10 20:59:08 UTC
Permalink
Post by Simon Clubley
Post by Jan-Erik Soderholm
All the "funny effects" you mention above, will still be seen by a user.
No, they won't.
Yes they will. Any user doing a DIR will see the timestamp jump
back and forth at the DST change.
Post by Simon Clubley
For a really simple example, makefiles...
That is for programmers, not ordinary users.

I fully understand that tools like "make" can work around it.
I was talking about the time stamp displayed by DIR.
Post by Simon Clubley
will still work
correctly if they are in use during a DST transition. Good luck with
trying to guarantee that at the moment. :-)
Few programmers are working at the time of the DST switchover... :-)
Post by Simon Clubley
Simon.
Johnny Billquist
2017-12-10 21:41:16 UTC
Permalink
Post by Jan-Erik Soderholm
Post by Simon Clubley
Post by Jan-Erik Soderholm
All the "funny effects" you mention above, will still be seen by a user.
No, they won't.
Yes they will. Any user doing a DIR will see the timestamp jump
back and forth at the DST change.
Right. But now it's an effect of the DIR command, and not the file
timestamp.
Post by Jan-Erik Soderholm
Post by Simon Clubley
For a really simple example, makefiles...
That is for programmers, not ordinary users.
It's always dangerous to try and separate people into boxes. :-)
Post by Jan-Erik Soderholm
I fully understand that tools like "make" can work around it.
I was talking about the time stamp displayed by DIR.
Well, make isn't "working around it". Make rather depends on having time
stamps which are increasing all the time. Having a DST move the time
back breaks things for such tools.

But indeed, the effect on tools are mostly not seen. They affect the
inner working of tools, and the effect is mostly difficult to spot.

A command like DIR is more obvious, since it's directly related to
displaying things to the user, and it should still cater for DST
changes, and different time zones.

However, here is another thing that would change, which is visible. If I
were to be logged into a computer (me being in Switzerland) and someone
else logged into that same computer from, say, Seattle.
I create a file at 13.30, local time. I then at 13.40 do a DIR command.
I will then see that this file was created at 13.30. The person in
Seattle does a DIR for the same file, at 04.40 (ie. the same time as I
am doing my DIR). For him, the file would be shown as created at 04.30,
ie 10 minutes before he did his DIR. Which is very correct and consistent.
If he did a DIR at 04.40, and saw that the file was created at 13.30, it
would appear it was created in the future, which is rather broken.

So this would be yet another example of a visible difference. Because
the file timestamp would actually be in UTC, and then each DIR command
would convert this timestamp into a printable date string, which also
includes adjusting for any timezone or DST state affecting this UTC time.
Post by Jan-Erik Soderholm
Post by Simon Clubley
will still work
correctly if they are in use during a DST transition. Good luck with
trying to guarantee that at the moment. :-)
Few programmers are working at the time of the DST switchover... :-)
Uh? Say what? Which reality are you living in. We must have accidentally
jumped between two parallel worlds. Not sure if it is you or I who
jumped. :-)

Johnny (who actually have been bitten by the DST switch and make tools)
--
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
Jan-Erik Soderholm
2017-12-10 21:49:42 UTC
Permalink
Post by Jan-Erik Soderholm
Post by Simon Clubley
Post by Jan-Erik Soderholm
All the "funny effects" you mention above, will still be seen by a user.
No, they won't.
Yes they will. Any user doing a DIR will see the timestamp jump
back and forth at the DST change.
Right. But now it's an effect of the DIR command, and not the file timestamp.
Post by Jan-Erik Soderholm
Post by Simon Clubley
For a really simple example, makefiles...
That is for programmers, not ordinary users.
It's always dangerous to try and separate people into boxes. :-)
Post by Jan-Erik Soderholm
I fully understand that tools like "make" can work around it.
I was talking about the time stamp displayed by DIR.
Well, make isn't "working around it". Make rather depends on having time
stamps which are increasing all the time. Having a DST move the time back
breaks things for such tools.
But indeed, the effect on tools are mostly not seen. They affect the inner
working of tools, and the effect is mostly difficult to spot.
A command like DIR is more obvious, since it's directly related to
displaying things to the user, and it should still cater for DST changes,
and different time zones.
However, here is another thing that would change, which is visible. If I
were to be logged into a computer (me being in Switzerland) and someone
else logged into that same computer from, say, Seattle.
I create a file at 13.30, local time. I then at 13.40 do a DIR command. I
will then see that this file was created at 13.30. The person in Seattle
does a DIR for the same file, at 04.40 (ie. the same time as I am doing my
DIR). For him, the file would be shown as created at 04.30, ie 10 minutes
before he did his DIR. Which is very correct and consistent.
If he did a DIR at 04.40, and saw that the file was created at 13.30, it
would appear it was created in the future, which is rather broken.
So this would be yet another example of a visible difference. Because the
file timestamp would actually be in UTC, and then each DIR command would
convert this timestamp into a printable date string, which also includes
adjusting for any timezone or DST state affecting this UTC time.
Post by Jan-Erik Soderholm
Post by Simon Clubley
will still work
correctly if they are in use during a DST transition. Good luck with
trying to guarantee that at the moment. :-)
Few programmers are working at the time of the DST switchover... :-)
Uh? Say what? Which reality are you living in. We must have accidentally
jumped between two parallel worlds. Not sure if it is you or I who jumped. :-)
    Johnny (who actually have been bitten by the DST switch and make tools)
OK. I think there isn't much more to say about this subject... :-)
A flat earth with one common time would be easier...

Even large companies like eBay asks everyone to use the "eBay Standard
Time" which is the TZ of California. So when I (in Sweden) sets the timed
released of my eBay auctions, I have to think in terms of California time.
And then find a point in time that best matches all parts of the world. :-)
Johnny Billquist
2017-12-10 22:04:07 UTC
Permalink
Post by Jan-Erik Soderholm
OK. I think there isn't much more to say about this subject... :-)
A flat earth with one common time would be easier...
Indeed. Let's declare it so. :-)
Post by Jan-Erik Soderholm
Even large companies like eBay asks everyone to use the "eBay Standard
Time" which is the TZ of California. So when I (in Sweden) sets the timed
released of my eBay auctions, I have to think in terms of California time.
And then find a point in time that best matches all parts of the world. :-)
Really? I have never used eBay, but that just sounds incredibly broken.
At the same time, it does show that people still tend to think and so
things in local time, even though the proper (and obvious) solution have
been around for 40 years.
I suspect "eBay standard time" also means that DST might be relevant,
making it even more interesting from Sweden, since they change to/from
DST at a different date in the US compared to Europe.
Ugh! :-(

(And with all that said, I also happen to know that Google made the same
stupidity, using Pacific time instead of UTC, with hilarious effects
twice a year because of it...)

Johnny
--
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
Paul Sture
2017-12-10 22:52:14 UTC
Permalink
Post by Johnny Billquist
Post by Jan-Erik Soderholm
OK. I think there isn't much more to say about this subject... :-)
A flat earth with one common time would be easier...
Indeed. Let's declare it so. :-)
Post by Jan-Erik Soderholm
Even large companies like eBay asks everyone to use the "eBay Standard
Time" which is the TZ of California. So when I (in Sweden) sets the timed
released of my eBay auctions, I have to think in terms of California time.
And then find a point in time that best matches all parts of the world. :-)
Really? I have never used eBay, but that just sounds incredibly broken.
At the same time, it does show that people still tend to think and so
things in local time, even though the proper (and obvious) solution have
been around for 40 years.
I suspect "eBay standard time" also means that DST might be relevant,
making it even more interesting from Sweden, since they change to/from
DST at a different date in the US compared to Europe.
Ugh! :-(
(And with all that said, I also happen to know that Google made the same
stupidity, using Pacific time instead of UTC, with hilarious effects
twice a year because of it...)
And Microsoft used Seattle time in Windows Server 2008 backup save set
names. US Date format too, which can be a source of confusion when you
are restoring from 6th June (or was it 6th July?) in the CET time zone.

This was when booting standalone, so you are at the command line. Server
2008 didn't ask you for your time zone as part of that boot process, and
of course your hardware clock is set to local time. Yuck.

From the example at:

<https://technet.microsoft.com/en-us/library/cc742118.aspx>

Examples

To start recovering the information from the backup that was run on
March 31, 2013 at 9:00 A.M., located on drive d:, type:

wbadmin start sysrecovery -version:03/31/2013-09:00 -backupTarget:d:
--
Everybody has a testing environment. Some people are lucky enough to
have a totally separate environment to run production in.
Paul Sture
2017-12-10 22:59:31 UTC
Permalink
Post by Paul Sture
Post by Johnny Billquist
Post by Jan-Erik Soderholm
OK. I think there isn't much more to say about this subject... :-)
A flat earth with one common time would be easier...
Indeed. Let's declare it so. :-)
Post by Jan-Erik Soderholm
Even large companies like eBay asks everyone to use the "eBay Standard
Time" which is the TZ of California. So when I (in Sweden) sets the timed
released of my eBay auctions, I have to think in terms of California time.
And then find a point in time that best matches all parts of the world. :-)
Really? I have never used eBay, but that just sounds incredibly broken.
At the same time, it does show that people still tend to think and so
things in local time, even though the proper (and obvious) solution have
been around for 40 years.
I suspect "eBay standard time" also means that DST might be relevant,
making it even more interesting from Sweden, since they change to/from
DST at a different date in the US compared to Europe.
Ugh! :-(
(And with all that said, I also happen to know that Google made the same
stupidity, using Pacific time instead of UTC, with hilarious effects
twice a year because of it...)
And Microsoft used Seattle time in Windows Server 2008 backup save set
names. US Date format too, which can be a source of confusion when you
are restoring from 6th June (or was it 6th July?) in the CET time zone.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
7th June (or was it 6th July?
--
"Over the next two weeks we visited dozens of Excel customers, and did
not see anyone using Excel to actually perform what you would call
'calculations'. Almost all of them were using Excel because it was a
convenient way to create a table." -- Joel Spolsky
David Froble
2017-12-11 00:38:31 UTC
Permalink
Post by Paul Sture
Post by Paul Sture
Post by Johnny Billquist
Post by Jan-Erik Soderholm
OK. I think there isn't much more to say about this subject... :-)
A flat earth with one common time would be easier...
Indeed. Let's declare it so. :-)
Post by Jan-Erik Soderholm
Even large companies like eBay asks everyone to use the "eBay Standard
Time" which is the TZ of California. So when I (in Sweden) sets the timed
released of my eBay auctions, I have to think in terms of California time.
And then find a point in time that best matches all parts of the world. :-)
Really? I have never used eBay, but that just sounds incredibly broken.
At the same time, it does show that people still tend to think and so
things in local time, even though the proper (and obvious) solution have
been around for 40 years.
I suspect "eBay standard time" also means that DST might be relevant,
making it even more interesting from Sweden, since they change to/from
DST at a different date in the US compared to Europe.
Ugh! :-(
(And with all that said, I also happen to know that Google made the same
stupidity, using Pacific time instead of UTC, with hilarious effects
twice a year because of it...)
And Microsoft used Seattle time in Windows Server 2008 backup save set
names. US Date format too, which can be a source of confusion when you
are restoring from 6th June (or was it 6th July?) in the CET time zone.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
7th June (or was it 6th July?
Situational awareness is everything ....

:-)
m***@gmail.com
2017-12-10 22:39:20 UTC
Permalink
Post by Jan-Erik Soderholm
Post by Jan-Erik Soderholm
Post by Simon Clubley
Post by Jan-Erik Soderholm
All the "funny effects" you mention above, will still be seen by a user.
No, they won't.
Yes they will. Any user doing a DIR will see the timestamp jump
back and forth at the DST change.
Right. But now it's an effect of the DIR command, and not the file timestamp.
Post by Jan-Erik Soderholm
Post by Simon Clubley
For a really simple example, makefiles...
That is for programmers, not ordinary users.
It's always dangerous to try and separate people into boxes. :-)
Post by Jan-Erik Soderholm
I fully understand that tools like "make" can work around it.
I was talking about the time stamp displayed by DIR.
Well, make isn't "working around it". Make rather depends on having time
stamps which are increasing all the time. Having a DST move the time back
breaks things for such tools.
But indeed, the effect on tools are mostly not seen. They affect the inner
working of tools, and the effect is mostly difficult to spot.
A command like DIR is more obvious, since it's directly related to
displaying things to the user, and it should still cater for DST changes,
and different time zones.
However, here is another thing that would change, which is visible. If I
were to be logged into a computer (me being in Switzerland) and someone
else logged into that same computer from, say, Seattle.
I create a file at 13.30, local time. I then at 13.40 do a DIR command. I
will then see that this file was created at 13.30. The person in Seattle
does a DIR for the same file, at 04.40 (ie. the same time as I am doing my
DIR). For him, the file would be shown as created at 04.30, ie 10 minutes
before he did his DIR. Which is very correct and consistent.
If he did a DIR at 04.40, and saw that the file was created at 13.30, it
would appear it was created in the future, which is rather broken.
So this would be yet another example of a visible difference. Because the
file timestamp would actually be in UTC, and then each DIR command would
convert this timestamp into a printable date string, which also includes
adjusting for any timezone or DST state affecting this UTC time.
Post by Jan-Erik Soderholm
Post by Simon Clubley
will still work
correctly if they are in use during a DST transition. Good luck with
trying to guarantee that at the moment. :-)
Few programmers are working at the time of the DST switchover... :-)
Uh? Say what? Which reality are you living in. We must have accidentally
jumped between two parallel worlds. Not sure if it is you or I who jumped. :-)
    Johnny (who actually have been bitten by the DST switch and make tools)
OK. I think there isn't much more to say about this subject... :-)
A flat earth with one common time would be easier...
Even large companies like eBay asks everyone to use the "eBay Standard
Time" which is the TZ of California. So when I (in Sweden) sets the timed
released of my eBay auctions, I have to think in terms of California time.
And then find a point in time that best matches all parts of the world. :-)
I can why eBay might do that.

Some people here seem to have the idea that time is either consistent or that the inconsistencies from location to location can somehow be managed around local time. Not while there's different time zones around the world it won't be.

They also have the idea that abrupt changes of time, as is the case switching to and from Daylight Saving Time, are easily managed. Again the answer is no.

The adjustment usually takes place around 3:00am Sunday morning because there's less happening. (Imagine if the change took place at 10:00am Monday morning!)

Depending on the processing on the system a step adjustment might be perfectly okay. Alternatively you might try a cycle that adjusts the system time by a small amount each time around before waiting some period before repeating the cycle, and stopping when the total adjustment is 60 minutes. Perhaps file version numbers will tell you which was created first regardless of the time stamp on the file. Alternatively you might want to have a file-creation sequence number associated with every file so that you can confidently determine which file was created first.

I just don't expect someone else to develop special software to cater for how I need to deal with changes made just twice in a year.

John
Simon Clubley
2017-12-11 00:15:58 UTC
Permalink
Post by m***@gmail.com
I can why eBay might do that.
Some people here seem to have the idea that time is either consistent or
that the inconsistencies from location to location can somehow be managed
around local time. Not while there's different time zones around the world
it won't be.
You seem to have missed the key concept here. In a UTC based system,
the system time is _always_ UTC. All that changes is your view into
that system time. 3PM for me is the same point in time as 5PM is for
a person located in a place that is a couple of standard one hour
timezones to the east of me.

In a UTC based system, programs written correctly deal only with
those points in time for internal processing. They don't care that
it's 3PM in one timezone or 5PM in another timezone.

What you see on your screen in a UTC based system is merely a local
view into the UTC system time.

In a VMS system operating on local time, those are two different
points in time with all the issues which arise from that.
Post by m***@gmail.com
They also have the idea that abrupt changes of time, as is the case
switching to and from Daylight Saving Time, are easily managed. Again the
answer is no.
I agree the answer is no on VMS. The same is not true on Unix.
Post by m***@gmail.com
The adjustment usually takes place around 3:00am Sunday morning because
there's less happening. (Imagine if the change took place at 10:00am
Monday morning!)
Depending on the processing on the system a step adjustment might be
perfectly okay. Alternatively you might try a cycle that adjusts the
system time by a small amount each time around before waiting some period
before repeating the cycle, and stopping when the total adjustment is 60
minutes. Perhaps file version numbers will tell you which was created
first regardless of the time stamp on the file. Alternatively you might
want to have a file-creation sequence number associated with every file so
that you can confidently determine which file was created first.
Or you can skip all that faffing around and just do what Unix does. :-)
Post by m***@gmail.com
I just don't expect someone else to develop special software to cater for
how I need to deal with changes made just twice in a year.
But that software is standard on other operating systems...

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
David Froble
2017-12-11 00:43:29 UTC
Permalink
Post by m***@gmail.com
Post by Jan-Erik Soderholm
Post by Jan-Erik Soderholm
Post by Simon Clubley
Post by Jan-Erik Soderholm
All the "funny effects" you mention above, will still be seen by a user.
No, they won't.
Yes they will. Any user doing a DIR will see the timestamp jump
back and forth at the DST change.
Right. But now it's an effect of the DIR command, and not the file timestamp.
Post by Jan-Erik Soderholm
Post by Simon Clubley
For a really simple example, makefiles...
That is for programmers, not ordinary users.
It's always dangerous to try and separate people into boxes. :-)
Post by Jan-Erik Soderholm
I fully understand that tools like "make" can work around it.
I was talking about the time stamp displayed by DIR.
Well, make isn't "working around it". Make rather depends on having time
stamps which are increasing all the time. Having a DST move the time back
breaks things for such tools.
But indeed, the effect on tools are mostly not seen. They affect the inner
working of tools, and the effect is mostly difficult to spot.
A command like DIR is more obvious, since it's directly related to
displaying things to the user, and it should still cater for DST changes,
and different time zones.
However, here is another thing that would change, which is visible. If I
were to be logged into a computer (me being in Switzerland) and someone
else logged into that same computer from, say, Seattle.
I create a file at 13.30, local time. I then at 13.40 do a DIR command. I
will then see that this file was created at 13.30. The person in Seattle
does a DIR for the same file, at 04.40 (ie. the same time as I am doing my
DIR). For him, the file would be shown as created at 04.30, ie 10 minutes
before he did his DIR. Which is very correct and consistent.
If he did a DIR at 04.40, and saw that the file was created at 13.30, it
would appear it was created in the future, which is rather broken.
So this would be yet another example of a visible difference. Because the
file timestamp would actually be in UTC, and then each DIR command would
convert this timestamp into a printable date string, which also includes
adjusting for any timezone or DST state affecting this UTC time.
Post by Jan-Erik Soderholm
Post by Simon Clubley
will still work
correctly if they are in use during a DST transition. Good luck with
trying to guarantee that at the moment. :-)
Few programmers are working at the time of the DST switchover... :-)
Uh? Say what? Which reality are you living in. We must have accidentally
jumped between two parallel worlds. Not sure if it is you or I who jumped. :-)
Johnny (who actually have been bitten by the DST switch and make tools)
OK. I think there isn't much more to say about this subject... :-)
A flat earth with one common time would be easier...
Even large companies like eBay asks everyone to use the "eBay Standard
Time" which is the TZ of California. So when I (in Sweden) sets the timed
released of my eBay auctions, I have to think in terms of California time.
And then find a point in time that best matches all parts of the world. :-)
I can why eBay might do that.
Some people here seem to have the idea that time is either consistent or that the inconsistencies from location to location can somehow be managed around local time. Not while there's different time zones around the world it won't be.
They also have the idea that abrupt changes of time, as is the case switching to and from Daylight Saving Time, are easily managed. Again the answer is no.
The adjustment usually takes place around 3:00am Sunday morning because there's less happening. (Imagine if the change took place at 10:00am Monday morning!)
Depending on the processing on the system a step adjustment might be perfectly okay. Alternatively you might try a cycle that adjusts the system time by a small amount each time around before waiting some period before repeating the cycle, and stopping when the total adjustment is 60 minutes. Perhaps file version numbers will tell you which was created first regardless of the time stamp on the file. Alternatively you might want to have a file-creation sequence number associated with every file so that you can confidently determine which file was created first.
I just don't expect someone else to develop special software to cater for how I need to deal with changes made just twice in a year.
John
Actually, it's once a year. Not really a problem when moving clocks ahead one
hour. Just nothing between 2:00 AM and 3:00 AM.

I seem to recall that something in VMS, or for VMS, instead of moving the clock
back one hour, slowed it down until it was back one hour. Thus, as things
happen, time is always moving ahead, not jumping backwards. Can't remember the
details.
Paul Sture
2017-12-10 22:00:18 UTC
Permalink
Post by Simon Clubley
Post by Jan-Erik Soderholm
All the "funny effects" you mention above, will still be seen by a user.
No, they won't.
Yes they will. Any user doing a DIR will see the timestamp jump back
and forth at the DST change.
Post by Simon Clubley
For a really simple example, makefiles...
That is for programmers, not ordinary users.
I fully understand that tools like "make" can work around it.
I was talking about the time stamp displayed by DIR.
Post by Simon Clubley
will still work correctly if they are in use during a DST transition.
Good luck with trying to guarantee that at the moment. :-)
Few programmers are working at the time of the DST switchover... :-)
What about automated software builds? A weekend is an excellent
time to kick a large build and regression test off :-)
--
Everybody has a testing environment. Some people are lucky enough to
have a totally separate environment to run production in.
David Froble
2017-12-11 00:46:19 UTC
Permalink
Post by Paul Sture
Post by Simon Clubley
Post by Jan-Erik Soderholm
All the "funny effects" you mention above, will still be seen by a user.
No, they won't.
Yes they will. Any user doing a DIR will see the timestamp jump back
and forth at the DST change.
Post by Simon Clubley
For a really simple example, makefiles...
That is for programmers, not ordinary users.
I fully understand that tools like "make" can work around it.
I was talking about the time stamp displayed by DIR.
Post by Simon Clubley
will still work correctly if they are in use during a DST transition.
Good luck with trying to guarantee that at the moment. :-)
Few programmers are working at the time of the DST switchover... :-)
What about automated software builds? A weekend is an excellent
time to kick a large build and regression test off :-)
Then do so on a development system using local time and no time changes, at
least during work.
David Froble
2017-12-10 17:00:16 UTC
Permalink
Post by Johnny Billquist
Post by m***@gmail.com
Post by Simon Clubley
[This is just something that occurred to me while looking at something
else. I don't recall seeing this discussed so apologies if it has been.]
Will the new VMS filesystem use the local system time on its timestamps
or will it use GMT and then convert to local time from there ?
If it does use the local system time, will it also store away the
timezone offset active at the point the timestamp was created ?
In the latter case, this would be the current numeric offset (+0100 for
example) and not the actual timezone identifier such as BST/EST/etc.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world
I don't get it. What exactly is wrong with having a system time
usually based on the location of the system? If you are accessing
that system then the time is whatever it is local to that system. Sure
there's an issue with network access and clusters split across time
zones, but is it really a big issue when you can work with relative
time (eg. +4:00)?
Time on early systems was not a big deal because users were local.
Clusters and networks only appeared later, besides which CPU time (and
memory) were expensive back in those days so developers didn't want to
waste them.
Is it really worth the time and effort to change the whole
time-handling system to satisfy what is likely to be some minority of
users? Sure you can dream up instances where it might be useful but
how many users would it be useful for?
And from the discussion here it's pretty obvious that you'd need
utilities to go with any changes so that system managers and operators
can see the time base that a given cluster member - or even user - is
using at the time.
Time handling might be a bit of a can worms at the moment but where's
the value in upgrading that a catering sized can?
Well, as people have pointed out, timezones are not static. Many places
include DST in the whole time zone mess, which means that if you use
local time, then you need to update your local time twice a year, and
you get funny effect, such as files being created in the future, the
same time repeating twice, hours that does not exist, and god knows what
falls out from all that.
It is, for many, really ugly, and is why you hear of places that shuts
everything down at DST change, and wait for an hour before starting
things up again.
And once you start trying to fix the whole DST mess, you inevitably gets
into the full scope of time zones, since that is just a milder form of
the DST mess.
TZ does matter. If you sit on a system, and you want to submit a job to
run at 10AM, you normally mean 10AM your local time, which might be a
very different time than what the system thinks, if it is in a different
time zone. The same if you want to find files changed today. When
"today" is differs depending on which time zone you are in.
I could go on, but I hope you get the picture...
Johnny
I'm pretty sure that John's point might be, the large majority of systems are
"local" systems with all users local. For such, using local time works just fine.

For those who need more, they really need more. My customers do have the
multiple time zone issue. It wasn't always thus, but it is now. I totally
understand the issue.
Simon Clubley
2017-12-10 19:25:24 UTC
Permalink
Post by David Froble
I'm pretty sure that John's point might be, the large majority of systems are
"local" systems with all users local. For such, using local time works just fine.
Unless you have processing going on across a DST transition at which
point many things most certainly do not work "just fine" at the moment.
Post by David Froble
For those who need more, they really need more. My customers do have the
multiple time zone issue. It wasn't always thus, but it is now. I totally
understand the issue.
You also need it when you have night time processing going on as well
even in just a single timezone.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
David Froble
2017-12-10 19:46:16 UTC
Permalink
Post by Simon Clubley
Post by David Froble
I'm pretty sure that John's point might be, the large majority of systems are
"local" systems with all users local. For such, using local time works just fine.
Unless you have processing going on across a DST transition at which
point many things most certainly do not work "just fine" at the moment.
Post by David Froble
For those who need more, they really need more. My customers do have the
multiple time zone issue. It wasn't always thus, but it is now. I totally
understand the issue.
You also need it when you have night time processing going on as well
even in just a single timezone.
Simon.
Neither of your statements make any sense at all, at least to me.

Using UTC instead of local time will have no effect at all on DST issues. Yes,
there will be an absolute timestamp. But whatever is implemented to translate
between UTC and local time will STILL see the one hour offset in a DST transition.

Nor do I see what night time processing might have to do with how an absolute
timestamp is stored.

Having an absolute timestamp appeals to me. The universe doesn't really care
about the rotation of a planet, and the perceptions of entities on said planet.
But as long as said entities wish to play around with time presentations,
there will be the inevitable side effects.
Simon Clubley
2017-12-10 20:11:23 UTC
Permalink
Post by David Froble
Post by Simon Clubley
Post by David Froble
I'm pretty sure that John's point might be, the large majority of systems are
"local" systems with all users local. For such, using local time works just fine.
Unless you have processing going on across a DST transition at which
point many things most certainly do not work "just fine" at the moment.
Post by David Froble
For those who need more, they really need more. My customers do have the
multiple time zone issue. It wasn't always thus, but it is now. I totally
understand the issue.
You also need it when you have night time processing going on as well
even in just a single timezone.
Neither of your statements make any sense at all, at least to me.
Using UTC instead of local time will have no effect at all on DST issues. Yes,
there will be an absolute timestamp. But whatever is implemented to translate
between UTC and local time will STILL see the one hour offset in a DST transition.
What you are missing is that the local time would just be a _view_
into the UTC system time. Internal processing would be done using
the UTC time so it would always be guaranteed to increase and at
a fixed rate without any jumps either forward or backwards.

Your view into the system time might jump (unless you output the
timezone along with the system time) but the actual time itself
will not.
Post by David Froble
Nor do I see what night time processing might have to do with how an absolute
timestamp is stored.
It does is you do that night time processing across a DST boundary.
Post by David Froble
Having an absolute timestamp appeals to me. The universe doesn't really care
about the rotation of a planet, and the perceptions of entities on said planet.
But as long as said entities wish to play around with time presentations,
there will be the inevitable side effects.
No method is 100% perfect, but the UTC system time with a local
view into that time is vastly superior to what we have at the moment.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
David Froble
2017-12-11 00:49:18 UTC
Permalink
Post by Simon Clubley
Post by David Froble
Post by Simon Clubley
Post by David Froble
I'm pretty sure that John's point might be, the large majority of systems are
"local" systems with all users local. For such, using local time works just fine.
Unless you have processing going on across a DST transition at which
point many things most certainly do not work "just fine" at the moment.
Post by David Froble
For those who need more, they really need more. My customers do have the
multiple time zone issue. It wasn't always thus, but it is now. I totally
understand the issue.
You also need it when you have night time processing going on as well
even in just a single timezone.
Neither of your statements make any sense at all, at least to me.
Using UTC instead of local time will have no effect at all on DST issues. Yes,
there will be an absolute timestamp. But whatever is implemented to translate
between UTC and local time will STILL see the one hour offset in a DST transition.
What you are missing is that the local time would just be a _view_
into the UTC system time. Internal processing would be done using
the UTC time so it would always be guaranteed to increase and at
a fixed rate without any jumps either forward or backwards.
Your view into the system time might jump (unless you output the
timezone along with the system time) but the actual time itself
will not.
I've always maintained that a person's perceptions is their reality. Perhaps a
person's view of a timestamp is also their reality.
Post by Simon Clubley
Post by David Froble
Nor do I see what night time processing might have to do with how an absolute
timestamp is stored.
It does is you do that night time processing across a DST boundary.
Post by David Froble
Having an absolute timestamp appeals to me. The universe doesn't really care
about the rotation of a planet, and the perceptions of entities on said planet.
But as long as said entities wish to play around with time presentations,
there will be the inevitable side effects.
No method is 100% perfect, but the UTC system time with a local
view into that time is vastly superior to what we have at the moment.
For some people, and some purposes ....
Continue reading on narkive:
Loading...