[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?

[Chris]

On 10/29/20 23:35, Stephen Hoffman wrote:
> On 2020-10-29 21:35:53 +0000, Jon Pinkley said:
>
>> 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.
>
> Change is feasible. It'd mean saved times on storage and timestamps
> elsewhere and prior to the migration would be ±13 hours or so, though.
> Among other wrinkles. But yes, compatibility claims another victim, here.
>
>> 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.
>>> ...
>>
>>> ‡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 most common answer to that question of mine has been "Oh!", and they
> seldom ask any more. If they do ask more, then discussing UTC is fodder.
> But they usually wander off. Sorting the audience being the intent of
> that question.
>
>> 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).
>
> Clusters are single timezone, too.
>
> All sorts of interesting timeouts and skews and thresholds and limits
> lurk here, too. DECset CMS will object for instance, should it detect a
> time off by more than 30 seconds.
>
>> 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.
>
> Sort of.
>
> There are calls for contending with that and most other time-related
> needs, among the C RTL calls, the UTC system service calls, and the DTSS
> calls.
>
> The classic system service calls, and the DCL commands associated with
> time, not so much.
>
> http://h30266.www3.hpe.com/odl/i64os/opsys/vmsos84/4493/4493pro_016.html#port_api
>
> http://h30266.www3.hpe.com/odl/i64os/opsys/vmsos84/5763/5763profile_068.html#tzset_function
>
> http://h30266.www3.hpe.com/odl/axpos/opsys/vmsos84/6677/6677pro_gen.html#heading_3.12
>
> etc
>
> The OpenVMS documentation here is scattered at best, and scattershot.
>
>> 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.
>
> Per process timezone is sort-of available. Per thread, AFAIK, is not.
>
>> 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
>> ...
>> 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.
>
> TZ is available. Sort of.
>
> But I long ago gave up and switched to UTC sans DST.
>
> Discussions around continuing with the use of localtime or switching to
> UTC have arisen with each previous port of OpenVMS, too.
>
>

How does VMS keep time ?. Does it use ntp, or some system of it's
own ?. Most of the world seems to use UTC +/- offset these days,
which seems sensible...

Chris