UTC Time in OpenVMS V7.2-1

[ngoht20]

WHen installing VMS, does the time by default is shown in UTC time or local?? In other words, when I do not select ANY timezones during the installation or setup of the system, does it automatically set its system time to UTC??

Secondly,

How many of you here as OpenVMS system admins set their OpenVMS systems to show UTC instead of local time??

I know that most UNIX systems prefer UTC. But what about VMS?

thanks

[ngoht20]

Another quick questions,

Sorry about the double posting but what if there is a huge OpenVMS datacenter and what time should the system be set to? UTC or local?

[Ian Miller.]

when you install VMS it asks which timezone.

If you can stick to UTC and avoid DST changes twice a year.

Standard advice - upgrade to a supported version. V7.2-1 has not been supported from sometime.

What are the application and user requirements ?
In which timezone are the users?

[Robert Gezelter]

ngoht20,

Yes, it is possible to run an OpenVMS system (or datacenter) directly on UTC (or any other timezone) merely by selecting the correct time zone. The Daylight savings time changes can be enabled or disabled.

Whether this is desirable or not depends on your setting. Some industries (e.g. aviation operations) inherently run on UTC. Other industries (e.g. banking systems) run inherently on local time, including the DST changes). Having logs in one time context and operating in a different time context can be confusing.

When one includes regulators and lawyers in the mix (as one is highly likely to), timestamps and transaction logs in the correct time context is a major issue.

In summary, time management is more than a technical issue. In your previous postings, you implied that your system was a business system. Having the wrong set of time stamps on a log could lead to expensive legal/accounting problems.

An issue that needs to be taken care of carefully (my internal systems run on Eastern Standard Time, year round, which I do not find an inconvenience). I have configured client systems for all of the various possibilities.

- Bob Gezelter, http://www.rlgsc.com

[Wim Van den Wyngaert]

IMHO the system and the database should reflect UTC because the other times change and have overlaps.

An application should store utc but present local time to the user. Even users from all kind of timezones should be able to work on 1 system. There is a product for helping you with that : http://www.softwarepartners.com/products/datesim/dsoverview.html

Wim

[Hoff]

Have you talked with your manager about your interest and your investigations into OpenVMS? (Time and timezones and timekeeping can easily be considered security-relevant.)

OpenVMS (unfortunately) uses the local time, and converts that time to get other times including UTC through various APIs. That decision was made in 1977 or so, and basically not one that can be changed without a major overhaul of everything everywhere.

Yes, even if the UTC happens to be the local time, then there can still be a conversion. It's the local time that's associated with all the classic OpenVMS objects (files, auditing, OPCOMs, everything), and it's local time that's displayed to all users. The objects don't have UTC values attached, just the 64-bit quadword OpenVMS-format time values.

Applications have a choice of what is selected and written, and that is the choice of the programmer. As for the internals, the classic APIs are all localtime. The C APIs are localtime to UTC to localtime.

There is no process-level timezone. Well, there is something that is sort of a process-level timezone, but it's only honored by specific interfaces. (See the Off By One Hour discussion in the FAQ.)

My preference is to use UTC within the application code I have control over, and stay as far away from timezones as I can manage. With OpenVMS, running anything other than local time generates user complaints and confusion. If you run UTC, anyone logged in will (unexpectedly) see UTC.

If you want to learn the details of how OpenVMS manages time and timekeeping and time zones and daylight saving time, it's a full chapter in the OpenVMS FAQ.

Most OpenVMS sites I am aware of run local time, and deal with the "fun" that is DST. Some run local time with no DST. Some do run UTC. That's a local call.

With a menu system such as you are apparently working with, I'd be seriously tempted to run UTC and -- since I have control of the displays through the menu -- it's entirely feasible to implement timezones and DST for each login; on the process level.

[ngoht20]

I know a friend of mine who manages IBM Mainframes for the City of Los Angeles and he told me that he DREADS the DST issues because he has to IPL all of his Mainframes to change the times...

IS this true for OPenVMS systems also is to IPL the systems?

[Jan van den Ende]

ngoht20

>>>IS this true for OPenVMS systems also is to IPL the systems?
<<<

NO.
To wit: we are aproaching 10 years uptime. And yet we in Europe go through DST changeover twice a year, and the date-of-change algorithm has chanced because of EU integration a few years back.

And I have no knowledge on them, but I find it hard to believe IBM have to reboot\t\o\o\b\e\r IPL for that. If true, that surely disappoints me in them!

fwiw

Proost.

Have one on me

jpe

[ngoht20]

Ok, so when it comes to DST, we do not have to IPL or power down OpenVMS systems...am I correct??? Or correct me if Im wrong...

And also, If I DO NOT DO NOTHING to set any timezones during install of OpenVMS, will OpenVMS use UTC by default???

Because I do want to use UTC. No mater what.

[Jan van den Ende]

ngoht20

>>>
And also, If I DO NOT DO NOTHING to set any timezones during install of OpenVMS, will OpenVMS use UTC by default???
Because I do want to use UTC. No mater what.
<<<

During install of VMS, you MUST choose a timezone. And in your case, you should choose UTC.


>>>
Ok, so when it comes to DST, we do not have to IPL or power down OpenVMS systems...am I correct???
<<<

Completely.
But, UTC is global, unified time, ONE clockreading worldwide independant of local solar time, that does NOT do any DST So, the issue of DST will not arise in your case. (nor does it in any tropical local time zone; in the southern temperate local zones the shifts are opposite, but in no way synchronous, to the northern ones. Because the all have much longer summer periods than winter periods).

hth

Proost.

Have one on me.

jpe

[Hoff]

Correctly-written applications and applications that are not time-sensitive will survive DST without a reboot. This is the case with most applications.

Incorrect-written and particularly time-sensitive applications can or will have problems.

Applications designed and implemented with no concept of DST -- and that also use the time values for certain ways, such as indexed keys -- can end up with corruptions.

OpenVMS itself can deal with DST just fine, and current releases can send DST notifications to allow applications to adapt dynamically.

There are systems around -- IBM MVS, OpenVMS, Linux and otherwise -- that can require a reboot to deal with the DST case. The vast majority do not.

V7.2-1 does not have the US DST changes, and no ECO is available. It's pretty old, too.

As for your particular installation, there is probably no issue with DST, or -- if there is -- the local management and IT team has a process for dealing with it. This case does arise twice a year, after all. And OpenVMS system and cluster uptimes of a decade or more are not unheard of. And those supporting applications generally learn about the DST switchover, particularly if they have made a mistake involving time and timekeeping.


Biggest single class of errors: using local time (with no TZ info) for unique record keys, and permitting the DST switch-over. This causes somebody problems once a year, as duplicates and sorting errors can arise when the DST moves back an hour. This coding error can arise regardless of the underlying operating system.

[Sebastian Bazley]

You also need to watch out for applications that do their own timezone calculations rather than relying on the host OS.

These include:

Java
Ingres (database)

there are no doubt others.

You need to ensure that any such products have also been set up to use UTC.

Hopefully this will be automatically picked up when the products are installed, but best to check just in case.