I just called GET-UNIVERSAL-TIME and it gave me what I
believe is a wrong answer. I don't recall it returning
this unexpected result before. I called GET-DECODED-TIME
and it gave me the answer that I expected.
Why does GET-DECODED-TIME think that daylight savings time
is in effect, but GET-UNIVERSAL-TIME does not?
I always thought that GET-DECODED-TIME was just shorthand
for (DECODE-UNIVERSAL-TIME (GET-UNIVERSAL-TIME))?
The clocks at my house (and the clock display on the computer)
think that it's really 15:34, not 14:34. DST is in effect.
So what's going on here?
CL-USER> (setq now (get-universal-time))
3305561645
CL-USER> (decode-universal-time now)
5
34
14
30
9
2004
3
NIL
5
CL-USER> (get-decoded-time)
15
34
15
30
9
2004
3
T
5
Is this broken?
Am I forgetting something important about GET-UNIVERSAL-TIME?
This is in LispWorks 4.1.20 on Windows 2000. Here's some internal
function I stumbled across. It eventually seems to call the Win32
GetTimeZoneInformation. It seems to be returning some stuff that
may be used by Lisp's universal time implementation; I am guessing:
SYSTEM::TIMEZONE (current Bias, minutes from GMT),
COMMON-LISP::*TIMEZONE-OFFSET* (StandardBias),
and SYSTEM::DAYLIGHT-BIAS (DaylightBias).
These values look right to me (GMT = EDT + 300 - 60).
I don't know what the other values are supposed to be.
CL-USER> (IO::IO-GET-TIMEZONE-INFORMATION)
300
0
-60
T
2
CL-USER> (lispworks:get-time)
15
41
9
952
That looks right, too.
GET-UNIVERSAL-TIME is implemented by calling GET-DECODED-TIME,
ENCODE-UNIVERSAL-TIME and doing something with SYSTEM::DAYLIGHT-BIAS.
I don't have the source; I wonder if it's doing something wrong.
Or have I just temporarily (?) lost my marbles?
(I sort of hope that the answer is "Yes".)
······@news.dtpq.com (Christopher C. Stacy) writes:
> I just called GET-UNIVERSAL-TIME and it gave me what I believe is a
> wrong answer. I don't recall it returning this unexpected result
> before. I called GET-DECODED-TIME and it gave me the answer that I
> expected.
>
> Why does GET-DECODED-TIME think that daylight savings time
> is in effect, but GET-UNIVERSAL-TIME does not?
Because GET-UNIVERSAL-TIME returns "an absolute time represented as a
single non-negative integer---the number of seconds since midnight,
January 1, 1900 GMT (ignoring leap seconds)." which isn't affected by
whether some particular locality observes daylight savings time.
> I always thought that GET-DECODED-TIME was just shorthand
> for (DECODE-UNIVERSAL-TIME (GET-UNIVERSAL-TIME))?
But DECODE-UNIVERSAL-TIME uses the current time zone if a time zone
isn't explicitly provided.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
In article <······················@ram.dialup.fu-berlin.de>,
···@zedat.fu-berlin.de (Stefan Ram) wrote:
> Peter Seibel quotes:
> >"an absolute time represented as a single non-negative
> >integer---the number of seconds since midnight, January 1, 1900
> >GMT (ignoring leap seconds)"
>
> AFAIK:
>
> A counter started exactly at that midnight and being
> incremented each second never can observe a leap second as
> such, which is a property of a given calendar not of the time.
>
> Because the method being described does not have anything to
> do with leap seconds, it also can not even ignore them.
>
> Moreover, it is also not clear what "ignoring leap seconds"
> would mean: Does it mean, the counter does /not/ count them,
> i.e., it is being halted during leap seconds (which is one way
> to ignore them), or it /does/ count them (ignoring that they
> are special in any way, i.e., ignoring their "leap" property,
> which is another way to "ignore" them)?
When you set the clock on a computer, you usually tell it the current
time using normal calendar and clock notation; the clock-setting
application has to convert that into an offset from some epoch for
internal storage, and this conversion might or might not take leap
seconds into account.
And even when Lisp is getting the time from the OS, it may be
represented as an offset from a different epoch than 1/1/1900 00:00 (for
instance, Unix uses 1/1/1970 00:00 as the epoch). Lisp has to add in
the offset between the two epochs, and the above requirement says that
it shouldn't include leap seconds in that offset.
I think it may be impossible in some environments for leap seconds to be
totally ignored. It's not really possible for Lisp to know whether the
mechanism used to set the OS clock incorporated them.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
···@zedat.fu-berlin.de (Stefan Ram) writes:
> Peter Seibel quotes:
>>"an absolute time represented as a single non-negative
>>integer---the number of seconds since midnight, January 1, 1900
>>GMT (ignoring leap seconds)"
>
> AFAIK:
>
> A counter started exactly at that midnight and being
> incremented each second never can observe a leap second as
> such, which is a property of a given calendar not of the time.
>
> Because the method being described does not have anything to
> do with leap seconds, it also can not even ignore them.
>
> Moreover, it is also not clear what "ignoring leap seconds"
> would mean: Does it mean, the counter does /not/ count them,
> i.e., it is being halted during leap seconds (which is one way
> to ignore them), or it /does/ count them (ignoring that they
> are special in any way, i.e., ignoring their "leap" property,
> which is another way to "ignore" them)?
>
> IMHO, Leap seconds might be taken into account or be ignored,
> when such a count is broken down into a special calendar time
> including calendar seconds, which often range from 0-59, but
> rarely might be 60 or 61 in some calendars on some special
> days. So that remark in parentheses could be moved to
> functions which do that task or else its meaning might need
> to be explained.
Okay. Take it up with the standard authors: I was just quoting the
Hyperspec.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
······@news.dtpq.com (Christopher C. Stacy) writes:
> Why does GET-DECODED-TIME think that daylight savings time
> is in effect, but GET-UNIVERSAL-TIME does not?
> I always thought that GET-DECODED-TIME was just shorthand
> for (DECODE-UNIVERSAL-TIME (GET-UNIVERSAL-TIME))?
Because GET-UNIVERSAL-TIME returns... the universal time?
i.e. the current time at Greenwhich? There's only one
current time at Greenwhich; it can't depend on where you
happen to be living.
Think of GET-UNIVERSAL-TIME as the value on that one clock
on which everyone agrees, all the time. [Modulo all the
problems that it isn't _really_ returning UT, etc. for implementation
reasons].
A truly correct implementation of GET-UNIVERSAL-TIME would probably
require an atomic clock and permanent network connection. :-)
I guess I stated the problem very poorly.
I am not asking what a universal time is,
or what GET-UNIVERSAL-TIME returns.
I am asking why:
(DECODE-UNIVERSAL-TIME (GET-UNIVERSAL-TIME))
is not the same as
(GET-DECODED-TIME)
In other words, I was thinking that DECODE-UNIVERSAL-TIME
took a GMT time as input, adjusted it for me according to
the (by default, local) timezone, and then returned the
result of that. (If I wanted an unmolested UT, I would
have to supply 0 for the timezone.)
But in fact, DECODE-UNIVERSAL-TIME is adjusting the time
the time for my current timezone, but without the DST bias.
It's returning TZ=5, DST-P=NIL, and the non-DST hour.
GET-DECODED-TIME, on the other hand, does both adjustments,
and returns the answer that I expect (current timezone, with
DST in effect as reflected in the hour, zone, and DST-P flag).
(Apparently I am idiotically wedged about somewhere here...)
In article <·············@news.dtpq.com>,
······@news.dtpq.com (Christopher C. Stacy) wrote:
> But in fact, DECODE-UNIVERSAL-TIME is adjusting the time
> the time for my current timezone, but without the DST bias.
> It's returning TZ=5, DST-P=NIL, and the non-DST hour.
>
> GET-DECODED-TIME, on the other hand, does both adjustments,
> and returns the answer that I expect (current timezone, with
> DST in effect as reflected in the hour, zone, and DST-P flag).
Lisp is presumed to know whether DST is currently in effect, but not
when DST changed in the past (or will in the future). So
GET-DECODED-TIME can adjust for the current zone. But
DECODE-UNIVERSAL-TIME doesn't know whether DST would be in effect on the
date that the time decodes to.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Barry Margolin <······@alum.mit.edu> writes:
> In article <·············@news.dtpq.com>,
> ······@news.dtpq.com (Christopher C. Stacy) wrote:
>
> > But in fact, DECODE-UNIVERSAL-TIME is adjusting the time
> > the time for my current timezone, but without the DST bias.
> > It's returning TZ=5, DST-P=NIL, and the non-DST hour.
> >
> > GET-DECODED-TIME, on the other hand, does both adjustments,
> > and returns the answer that I expect (current timezone, with
> > DST in effect as reflected in the hour, zone, and DST-P flag).
>
> Lisp is presumed to know whether DST is currently in effect, but not
> when DST changed in the past (or will in the future). So
> GET-DECODED-TIME can adjust for the current zone. But
> DECODE-UNIVERSAL-TIME doesn't know whether DST would be in effect on the
> date that the time decodes to.
I was thinking that DECODE-UNIVERSAL-TIME is supposed to supply
the current DST along with the current timezone -- the Hyperspec
actually says the following:
CLHS 25.2, "Function DECODE-UNIVERSAL-TIME":
If time-zone is not supplied, it defaults to the current
time zone adjusted for daylight saving time.
CLHS 25.2, "Function GET-UNIVERSAL-TIME, GET-DECODED-TIME":
Notes:
(get-decoded-time) == (decode-universal-time (get-universal-time))
Lispworks does:
(DECODE-UNIVERSAL-TIME (GET-DECODED-TIME)
(GET-UNIVERSAL-TIME))
53 57
7 7
1 2 ;2 AM EDT
1 1
10 10
2004 2004
4 4
NIL T ;Daylight
5 5 ;Eastern
The above result does tell me whether it did the DST adjustment,
but I think the spec says it's supposed to do the adjustment for me.
I think it's supposed to answer the question, "Suppose that we ignore
the given date, what time of day would this be in my locale today?"
Otherwise, DECODE-UNIVERSAL-TIME would always return NIL for DST.
CMUCL, CLISP, and Corman do what I expect.
Hence my suspicion that this is a bug in Lispworks.
(I wonder what a more recent version of Lispworks does.
Anybody got an evaluation version installed?)
Is there maybe some magic global flag somewhere that I've munged?
Am I still confused?
Christopher C. Stacy wrote:
> Hence my suspicion that this is a bug in Lispworks.
> (I wonder what a more recent version of Lispworks does.
> Anybody got an evaluation version installed?)
>
I don't know if it is this issue, but there have been timezone-related
problems in LW. I'm fairly sure I had a patch (from Xanalys) at some
point, although I don't think it's still needed. I'd ask Xanalys.
--tim
On Fri, 01 Oct 2004 06:32:51 GMT, ······@news.dtpq.com (Christopher C. Stacy) wrote:
> CLHS 25.2, "Function GET-UNIVERSAL-TIME, GET-DECODED-TIME":
>
> Notes:
> (get-decoded-time) == (decode-universal-time (get-universal-time))
>
>
> Lispworks does:
>
> (DECODE-UNIVERSAL-TIME (GET-DECODED-TIME)
> (GET-UNIVERSAL-TIME))
> 53 57
> 7 7
> 1 2 ;2 AM EDT
> 1 1
> 10 10
> 2004 2004
> 4 4
> NIL T ;Daylight
> 5 5 ;Eastern
>
>
> The above result does tell me whether it did the DST adjustment, but
> I think the spec says it's supposed to do the adjustment for me. I
> think it's supposed to answer the question, "Suppose that we ignore
> the given date, what time of day would this be in my locale today?"
> Otherwise, DECODE-UNIVERSAL-TIME would always return NIL for DST.
>
> CMUCL, CLISP, and Corman do what I expect.
>
> Hence my suspicion that this is a bug in Lispworks. (I wonder what
> a more recent version of Lispworks does. Anybody got an evaluation
> version installed?)
No, but I have 4.3.7 pro on Windows:
CL-USER 7 > (get-decoded-time)
18
6
10
1
10
2004
4
T
-1
CL-USER 8 > (decode-universal-time (get-universal-time))
19
6
10
1
10
2004
4
T
-1
The one second difference is obviously due to my slow typing
speed.
Time to upgrade... :)
Edi.
--
"Lisp doesn't look any deader than usual to me."
(David Thornley, reply to a question older than most languages)
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
······@news.dtpq.com (Christopher C. Stacy) writes:
> I am asking why:
>
> (DECODE-UNIVERSAL-TIME (GET-UNIVERSAL-TIME))
> is not the same as
> (GET-DECODED-TIME)
>
> (Apparently I am idiotically wedged about somewhere here...)
No, I wasn't wedged at all -- DECODE-UNIVERSAL-TIME was broken
in the older version of Lispworks that I was using. I have since
received a patch from Xanalys; current releases of Lispworks
do not have this problem.
On Fri, 01 Oct 2004 00:36:39 GMT, <······@news.dtpq.com> wrote:
Wow, my news service really sucks....
> I guess I stated the problem very poorly.
> I am not asking what a universal time is,
> or what GET-UNIVERSAL-TIME returns.
>
> I am asking why:
>
> (DECODE-UNIVERSAL-TIME (GET-UNIVERSAL-TIME))
> is not the same as
> (GET-DECODED-TIME)
>
> In other words, I was thinking that DECODE-UNIVERSAL-TIME
> took a GMT time as input, adjusted it for me according to
> the (by default, local) timezone, and then returned the
> result of that. (If I wanted an unmolested UT, I would
> have to supply 0 for the timezone.)
>
> But in fact, DECODE-UNIVERSAL-TIME is adjusting the time
> the time for my current timezone, but without the DST bias.
> It's returning TZ=5, DST-P=NIL, and the non-DST hour.
>
> GET-DECODED-TIME, on the other hand, does both adjustments,
> and returns the answer that I expect (current timezone, with
> DST in effect as reflected in the hour, zone, and DST-P flag).
>
> (Apparently I am idiotically wedged about somewhere here...)
In CMU 18e, it is the same here
LISP> (GET-DECODED-TIME)
7
30
15
3
11
2004
2
NIL
8
LISP> (DECODE-UNIVERSAL-TIME (GET-UNIVERSAL-TIME))
50
30
15
3
11
2004
2
NIL
8
outside of the seconds it took to read, copy and input your
statements...
--
Brownian motion is correctly colored.