Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site sftig.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!mhuxm!sftig!lr
From: lr@sftig.UUCP (L.Rosler)
Newsgroups: net.lang.c
Subject: Re: ANSI 'C'.
Message-ID: <628@sftig.UUCP>
Date: Thu, 21-Nov-85 23:40:42 EST
Article-I.D.: sftig.628
Posted: Thu Nov 21 23:40:42 1985
Date-Received: Sat, 23-Nov-85 06:09:07 EST
References: <447@graffiti.UUCP> <538@brl-sem.ARPA> <170@watmath.UUCP>
Organization: AT&T Bell Laboratories, Summit, NJ
Lines: 44

> In article <538@brl-sem.ARPA> ron@brl-sem.ARPA (Ron Natalie <ron>) writes:
> >
> >Eh?  The timezone never belonged in the operating system!  Unix time is GMT.
> >Most versions of UNIX these days use an environment variable to convey
> >timezone information to the user process.  All the C environment needs to
> >know is how to convert from GMT and LOCAL time to whatever the system uses
> >for time and back.  If you can't do this, it's likely to be impossible to
> >use times in C at all, regardless of how CTIME is specified.
> >
> The original problem still stands.  The ANSI standard is specifying that
> a library function be able to produce a value that is not available on
> a large number of systems.  No one really questions that Unix was right
> in deciding to store system time in GMT and make available information
> to compute some appropriate "local" time from GMT data.  However,
> believe it or not there are non-Unix environments out there.  No matter
> what the standard says, many operating systems do not have environment
> variables, and many of them do not keep time as GMT.  The only time
> function supplied by the operating system effectively returns the value on
> the wall clock beside the operator's console.  There is no available hint
> about the relation between this, and GMT or whether it is daylight
> savings time or not.
>   The standard has no real business specifying the environment in this
> amount of detail, or perhaps it should be worded with something like
> "If you are going to supply XXXX functionality, do it like this...".

Perhaps it is unrealistic to expect people who state what the "ANSI
standard is specifying" to have read it.  The draft actually says,
"The gmtime function returns ... a null pointer if GMT is not available."
The presumption is that if the time() function works at all (see my
previous posting on THAT subject), then it is reasonable to expect
localtime() to work also.  If gmtime() is available, it must work
as specified; otherwise it fails in a specified way.  In other words,
"If you are going to supply gmtime functionality, do it like this...".

>   I can live with the GETENV description since nothing stops me from
> just defining a GETENV that always returns NULL.  I can't really live
> with the requirement that I supply routines LOCALTIME, and GMTIME
> since both require me to return information that is not available to me.

But they don't.

Larry Rosler, AT&T
Editor, X3J11 C Standards Committee
(201) 522-5086