Re: [Chicken-users] srfi-19 timezone problems

[Kon Lovett]

On Mar 28, 2007, at 2:47 PM, Hans Bulfone wrote:

> hi,
<snip>
> but i still get the wrong result without TZ.  i think this is because
> seconds->local-time also returns the offset in seconds west of UTC.
>
> i must admit, i'm rather surprised about those different tz offset
> interpretations :)  until yesterday i thought everyone always means
> seconds east of utc, now i found out that the whole posix timezone api
> seems to use west of utc.
> there is no 'normal' way to specify the tz offset :)

MacOS X ctime manpage:

           char *tm_zone;  /* abbreviation of timezone name */
           long tm_gmtoff; /* offset from UTC in seconds */

     The field tm_isdst is non-zero if summer time is in effect.

     The field tm_gmtoff is the offset (in seconds) of the time  
represented
     from UTC, with positive values indicating east of the Prime  
Meridian.

So the result I see:

#;2> (vector-ref (seconds->local-time (current-seconds)) 9)
-25200

makes sense. Negative means west of the Prime Meridian and positive  
east, the opposite of the POSIX TZ variable.

The internals of srfi-19 use the above interpretation, not the TZ  
interp. As I said earlier I had my locale docu reversed & therefore  
assumed TZ worked like the srfi-19 internals. But now, as I guess you  
have seen, it negates the tm_gmtoff/tz-components offset values to  
switch between the two systems.

> btw, at least on my system, timezone (and thus
> (vector-ref (seconds->local-time (current-seconds)) 9))
> always returns -3600, no matter if it's summer time or not.

Me no like.

> this is also what localtime(3) says: [...] sets the external variables
> [...] timezone with the difference between UTC and local standard time
> in seconds, [...]
>
> tzset(3) contains the missing information about the sign:
> In a  SysV-like  environment  it  will  also set the variables
> timezone (seconds West of GMT)
>
> also, (local-timezone-abbreviation) always returns "CET" and
> never "CEST" on my system.

Me no like.

> so imho it should be
> (let ([tzo (vector-ref tv 9)]
> and
> (current-timezone
>   (string-append
>     tzn
>     (hms tzo)
>     UNKNOWN-LOCAL-TZ-NAME
>     (hms (- tzo DST-OFFSET))))
> in (local-timezone-locale), but i may be wrong, i'm too confused  
> now :)

Correct for you, wrong for me.

When a timezone is not set (note that Windows & MacOS X always have a  
tz set since they use a method separate from POSIX, although unix  
apps on the mac can use the POSIX api) then the '(local-timezone- 
locale)' is left to try to fake timezone offset & name info. This is  
a hack, and not a very good one. It relies on the OS knowing the  
timezone thru some other method, which on systems that use the POSIX  
TZ will be a problem.

For now always supply a TZ envvar.

I guess I can add '(local-timezone-locale)' hacks that are platform  
specific (Windows is already not well supported).

> ----
>
> C_decode_seconds in chicken's runtime.c contains this (version 2.6):
>
> #ifdef C_MACOSX
>                   C_fix(tmt->tm_gmtoff)
> #else
>                   C_fix(timezone)
> #endif
>
> my localtime(3) manpage (on linux) contains this:
>
>    The glibc version of struct tm has additional fields
>
>           long tm_gmtoff;           /* Seconds east of UTC */
>           const char *tm_zone;      /* Timezone abbreviation */
>
>    defined when _BSD_SOURCE was set before including <time.h>.
>    This is a BSD extension, present in 4.3BSD-Reno.
>
> if macosx has the same bsd extension, this means
> (vector-ref (seconds->local-time (current-seconds)) 9)
> will return a number with opposite sign on mac os x
> (but i cannot verify this as i don't have osx)
>
> this is all very confusing... :)
>
> bye,
> hans.