Hello
Have problem with time zone settings.
Time zone settings on my computer is +2.
$ date -R
Fri, 23 Mar 2001 20:23:04 +0200
$
USER> (encode-universal-time 0 0 0 1 1 1900)
-7200
(I expected +7200)
USER> (format-universal-time t (get-universal-time))
Friday, 3/23/01 08:25:02 pm [-2]
(I expected [+2]
NIL
USER> (get-decoded-time)
53
33
20
23
3
2001
4
NIL
-2
(I expected +2)
How can I change settings for Lisp system (if it possible
at all)?. I can hardcode timeline in all calls e.g. :timezone 2
etc. but it doesn't seem good solution and how I can affect
behavior of (get-universal-time), (get-decoded-time) ?
Using CMUCL 18c.
--
Vladimir Zolotych ······@eurocom.od.ua
In article <·················@eurocom.od.ua>,
Vladimir V. Zolotych <······@eurocom.od.ua> wrote:
> Hello
>
>Have problem with time zone settings.
>
>Time zone settings on my computer is +2.
>
>$ date -R
>Fri, 23 Mar 2001 20:23:04 +0200
...
>USER> (get-decoded-time)
>
>53
>33
>20
>23
>3
>2001
>4
>NIL
>-2
>(I expected +2)
In Common Lisp, the time zone is the number of hour *west* of GMT. The
output of "date" shows the number of hour *east* of GMT. That's why they
have opposite signs.
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Erik Naggum <····@naggum.net> writes:
> (apropos "ZONE") should reveal a variable that has the expected time zone
> value. This is unfortunately _not_ specified in the standard,
Part of the reason this is not standardized is alluded to in CLTL and probably
tucked away somewhere in ANSI CL as well. You can put whatever stock you want
in the reason, but it may actually turn out to have been a good idea sometime
in the near future: the idea was that a mobile computer (at the time, a tank,
but in the future probably a PDA) might want to be dynamically sensitive to
a change in timezone, such that static control through a variable might be
inappropriate. It was therefore left to individual vendors to come up with
an appropriate solution, which would be appropriate for later standardization
(if such ever happens).
> and
> there's no way to request a timezone other by the hours west of GMT,
> which means you lose time zone information and attendant rules, which can
> lead to serious loss of accuracy in the application using the results.
Well, you can always do everything GMT-relative for mission-critical
situations requiring precision... But mostly I agree with this criticism.