Subject: *default-time-zone* Defaults

From: [email-masked] (Joerg-Cyril Hoehle)
Date: Tue, 1 Feb 94 02:03:21 +0100

Hi,

I wonder why a parameter that seems to need local adjustement has found
neither entry nor comment into config.lsp.

Wouldn't it be wise to put a

(defparameter *default-time-zone* -1)	; default set in defs1.lsp

into non-UNIX cfg*.lsp files so that everybody sees what s/he has to adjust?

 	Joerg Hoehle.
[email-masked]

---

From: [email-masked] (Marcus Daniels)
Date: Mon, 31 Jan 94 17:23:27 PST

Joerg-Cyril> I wonder why a parameter that seems to need local
Joerg-Cyril> adjustement has found neither entry nor comment into
Joerg-Cyril> config.lsp.

I don't see any reason this parameter needs to exist at all.

Anyone care to comment?  I'd be inclined to just the UNIX code for
everyone (localtime vs gmtime).  It works for DOS, at least.

Unless someone objects, I'll just remove this parameter and rely 
on the user setting the timezone with environment variables.

---

From: [email-masked] (Joerg-Cyril Hoehle)
Date: Wed, 2 Feb 94 14:28:03 +0100

> everyone (localtime vs gmtime).  It works for DOS, at least.

DOS and UNIX is not all of the world. You cannot assume some
apparently standard C call on every platform.

You shouldn't even assume the existence of _any_ C function on any
system, for the following reason:

When building CLISP, one (of the many) thing(s) Bruno Haible had in
mind was portability and that many compilers libraries are broken
somewhere. He didn't want to let CLISP rely on a broken C library,
behaving differently when compiled with different compilers and their
libraries or with different versions of the same compiler. He tried to
exclusively use kernel or system calls.

For instance, the Amiga version of CLISP doesn't rely on any compilers
C library. I only had to write a small startup code and all the rest
is in the CLISP source. It doesn't use any malloc, strcmp, strcpy,
strlen, sprintf, fprintf or other such common C functions. It doesn't
use any time functions other than kernel ones. And it works with any
version of the OS that most users can remember. Current ports to other
platforms work the same way, only using the C library where
unavoidable (?), using the native system I/O, memory allocation, time
etc. mechanisms.

 > on the user setting the timezone with environment variables.

Why not just let that code remain in the source and bring it to the
users attention by putting this variable into config.lsp, like I
suggested in my previous mail? Not everybody has a TZ variable, uses a
TZ variable or sees the use for a TZ variable.

My points:

I strongly object removing this working code from CLISP.

I object intrdoducing into CLISP code the unnamed assumption that
everybody has some standard (maybe even worse: ANSI) C functions. The
way CLISP works so far is to define local files (unix.d, msdos.d etc.)
where #defines are kept and to write separate code in the different
modules where it is necessary.

If several platforms can share the same code then let them do so, but
remember that others may need special case code.

No offense intended,
 	Joerg Hoehle.

---

From: [email-masked] (Marcus Daniels)
Date: Wed, 2 Feb 94 06:14:22 PST

>> Unless someone objects, I'll just remove this parameter and rely on
>> the user setting the timezone with environment variables.

Joerg-Cyril> Why not just let that code remain in the source and bring
Joerg-Cyril> it to the users attention by putting this variable into
Joerg-Cyril> config.lsp, like I suggested in my previous mail? Not
Joerg-Cyril> everybody has a TZ variable, uses a TZ variable or sees
Joerg-Cyril> the use for a TZ variable.

The next release will repair this, one way or another.  DOS, for instance,
may allow the use of the C library gmtime/localtime as an option.

Joerg-Cyril> I object intrdoducing into CLISP code the unnamed
Joerg-Cyril> assumption that everybody has some standard (maybe even
Joerg-Cyril> worse: ANSI) C functions. The way CLISP works so far is
Joerg-Cyril> to define local files (unix.d, msdos.d etc.)  where
Joerg-Cyril> #defines are kept and to write separate code in the
Joerg-Cyril> different modules where it is necessary.

Understood.  That's why I ask.