nmurrayr@cc.curtin.edu.au (Ron Murray) (04/15/91)
While it's nice to see that programmers are beginning to realise that there
IS life outside their own country / timezone, it would be nice if they could
find some way of specifying this timezone without using a TZ environment
variable.
Perhaps I should explain. My interests are fairly wide-ranging, and they
include astronomy and various messaging systems. It seems, however, that
every man and his dog gets the brilliant idea of specifying the user's
time zone with an environment variable called. for some reason, "TZ". Even
that wouldn't be quite so bad if they all wanted it in the same format, but
some programs seem to want a three-letter code (e.g. "WST"), some want this
code but with a displacement from UTC added (and barf if it happens to be
negative!), and some are even worse. The result is that I can't have more
than one of these programs on my system at the same time, or one or more of
them gets upset, or more likely insists that the local time is 4 am when the
sun is shining outside.
It can't be that hard, fellas! Why not either find another way of specifying
time zone, or perhaps using your program's name in the variable (something
like "TZ_MYPROG" would do fine)?
Think about it.
.....Ron
--
===============================================================================
Internet: Murray_RJ@cc.curtin.edu.au | "You can lead a horse to
ACSnet: Murray_RJ@cc.cut.oz.au | water, but if you can
Bitnet: Murray_RJ%cc.curtin.edu.au@cunyvm.bitnet | get him to float on his
UUCP : uunet!munnari.oz!cc.curtin.edu.au!Murray_RJ | back you've really got
Amateur Packet Radio: VK6ZJM@VK6BBS.#WA.AUS.OC | something"
TCP/IP: 44.136.204.14, 44.136.204.19 | -- Murphy's Law I
===============================================================================st12a@menudo.uh.edu (richard henderson~) (04/15/91)
In article <1991Apr15.200244.7775@cc.curtin.edu.au> nmurrayr@cc.curtin.edu.au (Ron Murray) writes: > > While it's nice to see that programmers are beginning to realise that there >IS life outside their own country / timezone, it would be nice if they could >find some way of specifying this timezone without using a TZ environment >variable. > Perhaps I should explain. My interests are fairly wide-ranging, and they >include astronomy and various messaging systems. It seems, however, that >every man and his dog gets the brilliant idea of specifying the user's >time zone with an environment variable called. for some reason, "TZ". Even >that wouldn't be quite so bad if they all wanted it in the same format, but >some programs seem to want a three-letter code (e.g. "WST"), some want this >code but with a displacement from UTC added (and barf if it happens to be >negative!), and some are even worse. The result is that I can't have more >than one of these programs on my system at the same time, or one or more of >them gets upset, or more likely insists that the local time is 4 am when the >sun is shining outside. There _is_ a standard format for the TZ environment variable out there. There has been one for unix systems since the early 80s (I think). Now why people think they hav eto re-invent their own is another story. Here is the "official" format for this variable taken from MINIX POSIX source: * Time zones (TZ) are given as strings of the form (spaces only for clarity) * * Std Offset [Dst [Offset] [,Startdate[/Time], Enddate[/Time]]] * * where: * Std and Dst three or more bytes that are the designation for the standard * (std) or summer (dst) time zone. Only std is required; if dst * is missing, then summer time doen not apply in this locale. * * Offset and Indicates the value one must add to the local time to arrive * Time at Coordinated Universal Time. The offset has the form * hh[:mm[:ss]] * The hours shall be required and may be a single digit. If no * offset follows dst, summer time is assumed to be one hour ahead * of standard time. If preceded by a "-", the time zone shall be * east of the Prime meridian; otherwise it shall be west. Default * DST offset will be 1 hour, default switch Time will be 02:00:00 * * date The format of the date shall be one of the following: * Jn Julian day (1 <= n <= 365) * leapdays are NOT counted, so March 1 is always day 60 * n Zero-based Julian day (0 <= n <= 365) * leapdays are counted, so March 1 is day 61 in leapyears * Mm.n.d The d-th day (0<=d<=6) of week n (1 <=n<=5) of month * m (1<=m<=12), where week 5 means 'the last d day in * month m' which may occur in either the fourth or * fifth week. Week 1 is the first week in which d'th * day occurs. Day zero is sunday. * * See for more explanations on the TZ definition the IEEE Std 1003.1-1988 * Posix Standard, paragraphs 8.1.1 "Extensions to Time Functions" on 142-143. -------- richard~ st12a@menudo.uh.edu richard@stat.tamu.edu
mathew@mantis.co.uk (mathew) (04/16/91)
nmurrayr@cc.curtin.edu.au (Ron Murray) writes: > While it's nice to see that programmers are beginning to realise that ther > IS life outside their own country / timezone, it would be nice if they could > find some way of specifying this timezone without using a TZ environment > variable. The TZ environment variable is part of MS-DOS. Programs should not use it directly, but should use the supplied MS-DOS calls, as in the following MSC program: #include <stdio.h> #include <time.h> int daylight; long timezone; char *tzname[]; main() { time_t tnow; time(&tnow); printf(" Local time is %s\n",asctime(localtime(&tnow))); printf("Universal time is %s\n",asctime(gmtime(&tnow))); tzset(); printf("Daylight savings time flag = %d\n", daylight); printf("Time offset = %ld\n", timezone); printf("Time zone = %s\n", tzname[0]); } Any program which looks at TZ directly is evil and rude, and should not be tolerated. mathew [ GMT0BST ] -- If you're a John Foxx fan, please mail me!
flint@gistdev.gist.com (Flint Pellett) (04/18/91)
You can always fix it so that you can run all your conflicting applications at once by putting a "wrapper" around them: a small shell script or .bat file that fixes the conflicting variable, runs the application, and then (in the case of DOS) restores the original value of the variable. Of course, lots of people who only want to use the machine, not program it, don't know how to do this. As a developer, you can't win. As someone who has been through the problem of having used an environment var for a few years and then some new thing (in my case, Korn Shell) shows up and uses that same named environment var for something different, you are always at risk. Choosing a weird name may make the chances of a conflict less likely, but won't eliminate it. -- Flint Pellett, Global Information Systems Technology, Inc. 1800 Woodfield Drive, Savoy, IL 61874 (217) 352-1165 uunet!gistdev!flint or flint@gistdev.gist.com
jpn@genrad.com (John P. Nelson) (04/20/91)
>The TZ environment variable is part of MS-DOS. Huh? MSDOS has no special knowledge of the TZ environment variable. >Programs should not use it >directly, but should use the supplied MS-DOS calls, as in the following MSC >program: There ARE no MSDOS calls that use TZ. The braindamaged MSC library uses it, but this is far from being a standard feature. As far as I'm concerned, TZ should not be used. Period. john nelson uucp: {decvax,mit-eddie}!genrad!jpn domain: jpn@genrad.com
Ralf.Brown@B.GP.CS.CMU.EDU (04/20/91)
In article <41161@genrad.UUCP>, jpn@genrad.com (John P. Nelson) wrote: }There ARE no MSDOS calls that use TZ. The braindamaged MSC library uses }it, but this is far from being a standard feature. The reason that the MSC library uses it, as well as the TurboC/BorlandC and probably most other MSDOS C compilers' libraries, is that those functions which access TZ are fairly standard on Unix, and most C compilers strive for Unix compatibility in their libraries. -- {backbone}!cs.cmu.edu!ralf ARPA: RALF@CS.CMU.EDU FIDO: Ralf Brown 1:129/3.1 BITnet: RALF%CS.CMU.EDU@CMUCCVMA AT&Tnet: (412)268-3053 (school) FAX: ask DISCLAIMER? Did | It isn't what we don't know that gives us trouble, it's I claim something?| what we know that ain't so. --Will Rogers