ANSI 'C'.

[Snoopy]

In article <170 at watmath.UUCP> atbowler at watmath.UUCP (Alan T. Bowler [SDG]) writes:
>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.

System V uses $TZ to get timezone information, so each user can have their
own timezone.  (one point for sysV) But there doesn't seem to be anyway
to get other than USA style daylight savings time unless you have
source and can hack ctime.c, where the daylight time stuff is hardcoded
in. (minus 'n' points for sysV unless you live in the US)

4.2 has provisions for different types of daylight savings time,
which can be changed via settimeofday(2).  (The tables for
european daylight time are wrong, but better than nothing)
4.3 fixes (I think) the tables for europe, and adds one for
Canada, which was different than the US in '74 and '75.
(Like, who cares *now* ?)

I've modified date(1) for Utek 2.2, adding -z and -d options,
to set the timezone and type of daylight savings time.  I'm
thinking about teaching localtime(3) about $TZ, so that you
could type:  "TZ=some_other_zone date" and get the time for
some other timezone easily.  (e.g. to see if it's a good time
to call someone.)  comments?

>  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.   ...   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.
>  ...
>  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.

Let's be careful before we start throwing things away just because
some other system can't support it.  We can't make C fit the lowest
common denominator, because that's pretty low.   Throw away time
functions because the Fubar 2000 running SNAFUDOS can't support them,
and throw away floating point because the Whatiz 907 can't support it,
and throw away upper/lower case because...  (you get the idea)

Snoopy (ECS Ronin #901)
tektronix!tekecs!doghouse.TEK!snoopy