[Info-vax] SYS$TIMEZONE.DAT

[Stephen Hoffman]

On 2015-03-15 10:17:49 +0000, johnwallace4 at yahoo.co.uk said:

> On Saturday, 14 March 2015 15:52:03 UTC, Phillip Helbig (undress to 
> reply)  wrote:
>> In my 3-node cluster, one one node I have several versions of
>> SYS$TIMEZONE.DAT (on average, about one file is created every three
>> days) but on the others there is just one version.  The times are quite
>> different.
>> 
>> What process could be creating this file?
> 
> In the absence of other suggestions: VMS has historically been quite good
> at selectively auditing file system activity, and documentation of how to
> set up and use such auditing. Have you thought about giving that approach
> a go?
> 
> Sorry I can't suggest more detail, it's been a while...

SYS$TIMEZONE.DAT?  IIRC, that gets recreated at reboot, with various 
UTC$TIME_SETUP.COM usage, once or twice secondary to the DST 
switch-overs when the system manager screwed up and tried running with 
localtime with DST enabled and not with the correct UTC time and DST 
properly and permanently disabled, and probably at some other times 
over the lifetime of the system.

I don't think any of this stuff is documented anywhere, though.

Most of this morass being associated with the longstanding application 
compatibility of OpenVMS.  The added engineering effort and complexity 
arose when because the simple solution of moving the system clock over 
to UTC and switching processes to their own timezones would have broken 
this goal of application compatibility.  Too much of the existing 
application code and more than a little layered product and third-party 
code expects to get and to use a quadword localtime value.   The 
most-commonly-used system service APIs don't have any concept of 
timezone or DST or the rest.   The quadword localtime value inherently 
and inevitably became attached almost every object on OpenVMS; onto 
files, disk volumes, log timestamps, in DECnet network packets, etc.   
The quadword localtime handling around the DST change-over gets... ugly.

Getting everybody to fix the existing (and the inherently broken!) 
quadword time handling wasn't going to be popular, nor was it going to 
be entirely straightforward, and it would have involved deprecating the 
APIs and a fatal error and/or returning a bogus quadword time value and 
which would have gotten embedded, with all the problems that then 
entails.

Existing OpenVMS folks don't usually see the traditional OpenVMS 
localtime behavior as being inherently broken, though it is.  Most 
don't seem to mind that they can't run process-level or system level 
timezones, nor the ability to cluster across timezones, nor that the 
attached localtime values on objects and log file entries can vary by 
an hour when viewed from the other side of the DST change-over.  So 
there's that.   Those folks that do mine have long ago moved to the UTC 
system service calls, though — given UTC has to be back-calculated from 
localtime — the OpenVMS code underneath that is a little ugly, too.

Rather than forcing everybody over to UTC and fixing the APIs and 
fixing the broken code here and making the timestamps correct on 
current and new storage, more complexity was added.  For compatibility.

There are alway trade-offs in any large-scale software product, of 
course.  Managing an installed base is quite hard, and some decisions 
are difficult and expensive.  Fixing this morass would be small effort, 
and it'd mean that existing media, existing backups and existing 
logfile entries are basically forever broken, barring all sorts of 
massive and really ugly work to add 
MOUNT/TIMEZONE=tz/[NO]DAYLIGHT_SAVING_TIME and the underlying 
calculations onto... well... everything.  Most of the folks with 
existing applications would rather have the current (and broken!) 
behavior and traditional (broken) time-handling behavior and 
source-code and old-media compatibility, at least in the short term.

TL;DR: there's no OpenVMS tradition of deprecating even fundamentally 
broken APIs.

So here we are.


-- 
Pure Personal Opinion | HoffmanLabs LLC