[Chicken-hackers] Fixes for timezone problems

[Timothy Beyer]

Dear Chicken users of locale and srfi-19,

I finally fixed the timezone issues on my machine, (and most likely for all 
FreeBSD users in non-GMT locales) I don't know if anyone will find it useful, 
but the changes I made to runtime.c and posixunix.scm in the main distribution 
most likely will be useful to all chicken users.

I made the following changes to version 3.5.2, I don't think that 4.0 supports 
locale or srfi-19 yet, so for now I am stuck on an old version.

The third change is specific to the locale egg, and is more of a hack that the 
first two changes.

No changes were made to srfi-19

1) In runtime.c, I changed the else clause in C_decode_seconds from 
"C_fix(timezone)" to "C_fix(-tmt->tm_gmtoff)", as it does on Mac OS X.  This 
fixed the bizzare offset values, so I think that FreeBSD should be included in 
the #ifdef C_MACOSX conditional.

2)  In posixunix.scm, I noticed that the procedure local-timezone-abbreviation 
did not correctly determine the timezone on my machine.  All that I needed to 
change to fix the result, after comparing to my equivalent inline c function 
was changing "time_t clock = (time_t)0;" to "time_t clock = time(NULL);".

I don't know if those procedures have been changed in chicken 4.0, but it 
wouldn't yet be relevant because as far as I know, the locale and srfi-19 eggs 
have not yet been ported to chicken 4.0.  (If it supports these, I can try my 
changes on 4.x)

3) and finally, some changes to locale (version 0.5.1, which I think is the 
newest) were needed, due to erroneous timezone parsing (which seems impossible 
to get an accurate result from, anyway.)  So I just used good old C get 
reliable results... (see patch)

In the locale changes, I basically used c functions to create timezone 
components instead of parse-posix-literal-timezone; I simply override that 
invocation in the else clause with create-timezone-components (see included 
patch).  I realize that it is a hack, and might even redundantly repeat 
existent functions, but it works reliably. (I would suspect for most users of 
chicken on a posix system.)

I hope this helps, I can try to integrate more polished code into locale if Kon 
is interested.  (I'm sure he has a more elegant way of fixing the problem, but 
I figured I would share my solution for others to use in the meantime)

Regards,
Tim

locale-posix.scm.diff
Description: Binary data