Tech Insider					     Technology and Trends


			      USENET Archives

Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site asgb.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!bmcg!asgb!nkn
From: n...@asgb.UUCP
Newsgroups: net.unix-wizards
Subject: TZ in Other Countries
Message-ID: <561@asgb.UUCP>
Date: Fri, 26-Oct-84 18:10:11 EST
Article-I.D.: asgb.561
Posted: Fri Oct 26 18:10:11 1984
Date-Received: Sun, 28-Oct-84 06:34:15 EST
Organization: Burroughs Corporation, Boulder Colo.
Lines: 23


NOTE:
	The following refers to AT&T's UNIX(tm).  It may or may not also
apply to Berkeley versions.

	I would like to know how UNIX installations outside of the U.S.A.
manage Day Light Savings  in their ctime(3C) routines.  There  is code in
tzset() (which  is called by all of the ctime routines) to move the clock
ahead (back) at the appropriate time of the year.
	I know that some other countries  move their clocks  at different
times of the year  from us.  Also, some  countries have time  zones which
are not in hour  jumps, but  increments of  15 or 30 minutes.  I am  very
curious as to how UNIX sites outside of the U.S.A. have  accommodated the
assumptions built into ctime.  If you haven't had to modify ctime because
the assumptions work in your country,  I'd also be  interested in hearing
that.
	Please mail me your responses; it's probably not worth cluttering
up the net just to satisfy my curiosity.
	As usual, thanks in advance.

Neil Nelson
Burroughs Advanced Systems Group
. . .!sdcsvax!bmcg!asgb!nkn

Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site rlgvax.UUCP
Path: utzoo!linus!decvax!genrad!mit-eddie!godot!harvard!seismo!rlgvax!guy
From: g...@rlgvax.UUCP (Guy Harris)
Newsgroups: net.unix-wizards
Subject: Re: TZ in Other Countries
Message-ID: <221@rlgvax.UUCP>
Date: Mon, 29-Oct-84 18:18:12 EST
Article-I.D.: rlgvax.221
Posted: Mon Oct 29 18:18:12 1984
Date-Received: Fri, 2-Nov-84 02:44:59 EST
References: <561@asgb.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 55

> NOTE:
> 	The following refers to AT&T's UNIX(tm).  It may or may not also
> apply to Berkeley versions.
> 
> 	I would like to know how UNIX installations outside of the U.S.A.
> manage Day Light Savings  in their ctime(3C) routines.  There  is code in
> tzset() (which  is called by all of the ctime routines) to move the clock
> ahead (back) at the appropriate time of the year.
> 	I know that some other countries  move their clocks  at different
> times of the year  from us....

This is one thing that 4.2 has worked on; AT&T should pick it up (preferably
intact, unless they've got one that's *significantly* better - no reason
to be different from 4.2 just for the sake of being different).  Instead of
a binary "daylight savings time is in use here" flag, there's a "type of
daylight savings time" flag.  A value of 0 means no DST, and a non-zero
value selects one of several tables indicating the start and end of DST.

> Also, some  countries have time  zones which are not in hour  jumps, but
> increments of  15 or 30 minutes.

AT&T should put in a trivial fix to this; they should permit the time zone
offset to be of the form "hours:minutes", such as

	QST7:30QDT

where Quahog Standard Time is 7 hours 30 minutes away from GMT.

While they're at it, they should provide a way of getting the time zone
other than from the TZ environment variable, because

1) It's a royal pain in the *ss to make sure every program has the TZ
variable set; putting in /etc/profile is *not* sufficient, as not all
login shells are Bourne shells that read /etc/profile!  Furthermore,
in a vanilla S3 system (and, I think, a vanilla S5 system), setting
the environment of the "getty" command doesn't help because "login"
blows away its environment and replaces it with a freshly-crafted one
that doesn't have TZ (or TERM, thus forcing you to set TERM every time
you log in, even if the system knows that you're logging in from the VT100
at your desk).

2) You can fool programs like "uucp" into making calls to other systems
outside of the hours specified in the L.sys file by faking the time zone
offset.  (Thanks to Mark Horton for poiinting this one out.)

Getting it from the OS, as was done in V7, would be nice; either it could
be set at sysgen time, or by a system call or just a command which writes on
/unix and /dev/kmem.  If TZ is present, it'll use that, otherwise it'll use
the value from the OS (rather than the hardcoded EST5EDT that it currently
uses if TZ is missing).  Programs which don't want TZ faked out can do
a "putenv" to stomp on TZ (making it a null string, say), and the "ctime"
routines should use the value from the OS.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO vs IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or
research.

Electronic mail:			       WorldWideWeb:
   tech-insider@outlook.com			  http://tech-insider.org/