ANSI 'C'.

[Alan T. Bowler [SDG]]

In article <538 at brl-sem.ARPA> ron at 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...".

  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.