[Info-vax] Does anyone know if the unsupported TBO (time boost utility that "drifts" time forward or backward by adjusting ticklength) was every ported to the Itanium?

[Jon Pinkley]

On Thursday, October 29, 2020 at 11:24:11 AM UTC-4, Stephen Hoffman wrote:
> I love OpenVMS timekeeping. Not.

I am not in love with OpenVMS timekeeping either.  The way the whole TDF mechanism works seems backward to me, i.e. setting UTC as the offset from local time instead of what seems more appropriate to me, setting the "Local" time as an offset from UTC (which the clock should be based on).  And the latest change to the CRTL to deal with TDF was in my opinion, a Rube Goldberg "solution".  Sort of like the Ptolemaic Model to explain retrograde planetary motion.

And now there another "design" that can't be fixed because it will break backward compatibility.

What was really needed was a way to have per process time zones, and have the 64bit base epoch system time be 17-NOV-1858 00:00:00.00 UTC.  

> †Yes, I know from UTC and TAI and have some familiarity with the rest 
> of the timekeeping morass, thank you very much. Neither UTC nor TAI 
> ever decrement.

http://leapsecond.com/java/gpsclock.htm
https://www.timeanddate.com/time/universal-time.html

> ‡I've asked a few users over the years whether they'd considered that 
> the server might be located in England.

But even England has BST British Summer Time.  And it is not coordinated with USA DST.

The problem is that we no longer live in a "local world", and many VMS systems are used be people in many time zones (and tz rules).

But then every customer/application must develop their own way to deal with how time will be stored and displayed.  It is easy enough to have offsets from UTC and display time in an application in a user's time zone, but that doesn't fix the show time output at DCL and in the queue manager, etc.

I agree that TDF (local base time to UTC offset) should really be zero.  But I do wish there were VMS provided time services to get/display time in other time zones, and that these tz offsets would be automatically maintained by VMS.

But unix/linux doesn't get this correct either, i.e. I am not aware of per process/task/fork/thread tz in unix, but I'm not an expert unix/linux user either.

It isn't an "easy" problem to solve in a way that will please everyone, so DEC just put the problem in the customer's lap, and then there is no "standard" solution.  Are file dates stored in "UTC", and if so, will the times displayed be wrong when the offset is changed.  Dealing with time zones is a pain

The Problem with Time & Timezones - Computerphile
https://www.youtube.com/watch?v=-5wpm-gesOY

But this is a longstanding problem recognized early in VMS.  There was an article in (I believe the PageSwapper) by Don Golden(?), with a title like "Just a Modest Proposal" where it was proposed that VMS time should always be UTC (perhaps it used GMT) and that there should be an offset for the local time.

The base time 0h 17-NOV-1858 is supposedly based on the MJD introduced by SAO in 1957, and by definition that is UT based. 

Before I go too far off the main topic, I will say that I hope when the new SYSUAF layout that supports longer password hashes is cast in stone, it would be nice if there was a reserved field for a per user time offset/tz rule that could be used to provide a default, if OpenVMS ever does support per process tz rules.

Another thing it should have is a field to store the "Account Creation Date", as there is nothing there currently (other than the "UAI$_USER_DATA" blob, where a customer could store it, but then there is no standard way), and the closest thing there is is looking at the creation date of the user's UAF Default directory, aka sys$login directory, but that isn't an accurate mechanism, since moving a user to another disk will cause that date to change.

And if it ever does support per user tz, it should be possible for a user to "change" the tz from a DCL/RTL so that the process could view the time from a different perspective.