From: ericv@hornet (Developer)
Subject: TIMEZONE ON VMS
Date: 1995/07/29
Message-ID: <3vc1um$o6@mars.earthlink.net>#1/1
X-Deja-AN: 107042548
organization: Earthlink Network, Inc.
keywords: timezone, openvms, built-in
newsgroups: comp.os.vms
summary: Is there a way to get the timezone from OpenVMS?
Is there a way of implementing the retrieval of the machine's
timezone when using any language on VMS? Sort of like getting
the date, or time, etc. Just hardcoding it into a program
is not an option.
Thanks for any replies.
regards,
Eric Verwijs
er...@hornet.wlv.esltd.com (until 28 July 1995) or
verw...@esltd.com or
ah...@freenet.carleton.ca
"Black flies, the little black flies.
Always the black flies no matter where you go.
I'll die with a black fly picking my bones
In North Ontario-io in North Ontario."
Black Fly Song by Wade Hemsworth
From: co...@btgmax.zko.dec.com (Ken Cowan)
Subject: RE: TIMEZONE ON VMS
Date: 1995/07/31
Message-ID: <3vipkg$u9n@nntpd.lkg.dec.com>#1/1
X-Deja-AN: 107292253
distribution: world
references: ,<3vc1um$o6@mars.earthlink.net> <3vh4ht$gd2@ra.ibr.cs.tu-bs.de>
organization: Digital Equipment Corporation
reply-to: co...@rtl.enet.dec.com
newsgroups: comp.os.vms
In article <3vh4ht$...@ra.ibr.cs.tu-bs.de>, me...@ifn.ing.tu-bs.de writes:
|>In Article <3vc1um...@mars.earthlink.net>
|>ericv@hornet (Developer) writes:
|>>
|>>Is there a way of implementing the retrieval of the machine's
|>>timezone when using any language on VMS? Sort of like getting
|>>the date, or time, etc. Just hardcoding it into a program
|>>is not an option.
|>
|> I'm just finishing my work an a module containing replacement
|> routines for all the C RTL routines which are expected to handle
|> timezone and daylight saving times.
|>
|> Note that VMS always uses the local time, it has no knowledge of
|> GMT, timezones and daylight saving time.
|>
|> To implement the full POSIX behaviour of the time routines, my routines
|> expect a logical in the same format than VMS POSIX does. time()
|> then returns the seconds elapsed since 1-JAN-1970 GMT. Other routines
|> like localtime(), mktime() etc, also handle the GMT based clock values.
|> Daylight saving time is fully supported.
|>
|> The package is written in C (VAXC on VAX, DECC on Alpha) and uses
|> the RTL calendar routines localtime() and mktime() to do their work.
|>
|> Please wait a few days until the beta release will be announced.
|>
|> --Eckart
|>
|>-----------------------------------------------------------------------------
|>Eckart Meyer Address: Schleinitzstr. 23
|>Institute for Telecommunication 38092 Braunschweig
|>Technical University of Braunschweig Germany
|> Phone: +49 531 391 2454
|>E-Mail: me...@ifn.ing.tu-bs.de FAX: +49 531 391 5192
|>VMSmail: PSI%26245050351130::MEYER (DATEX-P)
|>-----------------------------------------------------------------------------
|>
|>
|>
There is a VMS system service, $GETUTC that returns UTC. It relies
on the timezone differential being setup by the system manager.
See SYS$MANAGER:UTC$CONFIGURE_TDF.COM.
The DEC C library interface to timezones should be available in the first
field test of OpenVMS V7.0.
--
Ken Cowan, ZK2-3/Q8 co...@rtl.enet.dec.com
Digital Equipment Corporation decwrl!rtl!cowan
110 Spit Brook Rd,
Nashua, NH 03062
From: egg...@twinsun.com (Paul Eggert)
Subject: Re: TIMEZONE ON VMS
Date: 1995/08/02
Message-ID: <3vpota$pto@shade.twinsun.com>#1/1
X-Deja-AN: 107434430
references: <3vc1um$o6@mars.earthlink.net> <3vh4ht$gd2@ra.ibr.cs.tu-bs.de>
<3vipkg$u9n@nntpd.lkg.dec.com>
organization: Twin Sun Inc, El Segundo, CA, USA
newsgroups: comp.os.vms
co...@btgmax.zko.dec.com (Ken Cowan) writes:
>The DEC C library interface to timezones should be available in the first
>field test of OpenVMS V7.0.
I hope that that library supports not only Posix time zone
specifications, but also Olson's common extension to Posix.
The Olson extension allows for much simpler TZ strings,
and it does not botch timezone histories like Posix does.
For example, suppose you're in Berlin. Posix says you should set TZ to
some complicated hieroglyphics like 'MET-1:00MET DST,M3.5.0/2:00,M9.5.0/3:00'.
(Imagine the hassles your support people will have explaining _that_ string
to people just setting up their new VMS box...)
And you'll have to change TZ to 'MET-1:00MET DST,M3.5.0/2:00,M10.5.0/3:00'
next year, since Germany will use different daylight savings rules in 1996.
Worse, when you do change TZ, your implementation will handle 1995 times
incorrectly, since it will incorrectly use 1996 rules when interpreting
1995 times.
In contrast, with the Olson extension, you just set TZ to 'Europe/Berlin'.
The Olson code knows about the rule changes, and it reports old times correctly.
In fact, the Olson tables record Berlin's GMT offset changes all the way
back to 1893, when Berlin first started using standard time.
This extension is supported in many Unix implementations, e.g.
SunOS/Solaris, Unixware, Nextstep, Linux. Implementing it is easier
than it might sound at first, since the tables and C code to implement it
are widely used and are in the public domain;
see <ftp://elsie.nci.nih.gov/pub/tz*>.
From: co...@btgmax.zko.dec.com (Ken Cowan)
Subject: Re: TIMEZONE ON VMS
Date: 1995/08/04
Message-ID: <3vtag7$mrv@nntpd.lkg.dec.com>#1/1
X-Deja-AN: 107561813
distribution: world
references: <3vc1um$o6@mars.earthlink.net> <3vh4ht$gd2@ra.ibr.cs.tu-bs.de>
<3vipkg$u9n@nntpd.lkg.dec.com> <3vpota$pto@shade.twinsun.com>
organization: Digital Equipment Corporation
reply-to: co...@rtl.enet.dec.com
newsgroups: comp.os.vms
In article <3vpota$...@shade.twinsun.com>, egg...@twinsun.com (Paul Eggert) writes:
|>co...@btgmax.zko.dec.com (Ken Cowan) writes:
|>
|>>The DEC C library interface to timezones should be available in the first
|>>field test of OpenVMS V7.0.
|>
|>I hope that that library supports not only Posix time zone
|>specifications, but also Olson's common extension to Posix.
|>The Olson extension allows for much simpler TZ strings,
|>and it does not botch timezone histories like Posix does.
|>
|>For example, suppose you're in Berlin. Posix says you should set TZ to
|>some complicated hieroglyphics like 'MET-1:00MET DST,M3.5.0/2:00,M9.5.0/3:00'.
|>(Imagine the hassles your support people will have explaining _that_ string
|>to people just setting up their new VMS box...)
|>And you'll have to change TZ to 'MET-1:00MET DST,M3.5.0/2:00,M10.5.0/3:00'
|>next year, since Germany will use different daylight savings rules in 1996.
|>Worse, when you do change TZ, your implementation will handle 1995 times
|>incorrectly, since it will incorrectly use 1996 rules when interpreting
|>1995 times.
|>
|>In contrast, with the Olson extension, you just set TZ to 'Europe/Berlin'.
|>The Olson code knows about the rule changes, and it reports old times correctly.
|>In fact, the Olson tables record Berlin's GMT offset changes all the way
|>back to 1893, when Berlin first started using standard time.
|>
|>This extension is supported in many Unix implementations, e.g.
|>SunOS/Solaris, Unixware, Nextstep, Linux. Implementing it is easier
|>than it might sound at first, since the tables and C code to implement it
|>are widely used and are in the public domain;
|>see <ftp://elsie.nci.nih.gov/pub/tz*>.
|>
Absolutely! You'll get zic so you can define your own rules or
get the latest ones from the net. We'll ship the rules in source form
if you just need to tweak them.
--
Ken Cowan, ZK2-3/Q8 co...@rtl.enet.dec.com
Digital Equipment Corporation decwrl!rtl!cowan
110 Spit Brook Rd,
Nashua, NH 03062