chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Hans Bulfone
Subject: Re: [Chicken-users] srfi-19 timezone problems
Date: Wed, 28 Mar 2007 23:47:31 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

hi,

On Tue, Mar 27, 2007 at 06:28:28PM -0700, Kon Lovett wrote:
> Yes. The TZ env-var is parsed properly by the locale egg but the tz- 
> offset was used incorrectly by my srfi-19 code. (Well, I did have my  
> locale documentation wrong. Said the opposite of what is true.)
> 
> 2.6.3 will be available Wed (earlier if I can figure out why I can't  
> build).

thank you!

it's now working correctly with TZ=CEST-2:00 (which i must admit
i haven't tried before).

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 :)

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.

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.

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 :)

----

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]