Would you mind to explain me the following result:
* (decode-universal-time (encode-universal-time 0 0 0 15 5 2001 -2))
0
0
1 ; <<<< This puzzles me
15
5
2001
1
T
-2
*
--
Vladimir Zolotykh
Vladimir,
which implementation and version are you using?
LW 4.2.6 shows
CL-USER 1 > (decode-universal-time
(encode-universal-time 0 0 0 15 5 2001 -2))
0
0
0
15
5
2001
1
T
-1
Regards,
S.
On Sat, 18 May 2002 11:57:34 +0300,
Vladimir Zolotykh <······@eurocom.od.ua> wrote:
> Would you mind to explain me the following result:
>
> * (decode-universal-time (encode-universal-time 0 0 0 15 5 2001 -2))
>
> 0
> 0
> 1 ; <<<< This puzzles me
> 15
> 5
> 2001
> 1
> T
> -2
> *
>
Stefan Schmiedl wrote:
>
> which implementation and version are you using?
I see reported result both in Allegro 6.1 and CMUCL-18c.
--
Vladimir Zolotykh
Vladimir Zolotykh <······@eurocom.od.ua> writes:
> Would you mind to explain me the following result:
>
> * (decode-universal-time (encode-universal-time 0 0 0 15 5 2001 -2))
>
> 0
> 0
> 1 ; <<<< This puzzles me
> 15
> 5
> 2001
> 1
> T
> -2
> *
Quoting from the HyperSpec, entry for encode-universal-time:
encode-universal-time converts a time from Decoded Time format to a
universal time.
If time-zone is supplied, no adjustment for daylight savings time is
performed.
And the entry for decode-universal-time:
Returns the decoded time represented by the given universal time.
If time-zone is not supplied, it defaults to the current time zone
adjusted for daylight saving time. If time-zone is supplied, daylight
saving time information is ignored. The daylight saving time flag is
nil if time-zone is supplied.
So the reason you are seeing the difference is that you did supply an
explicit time-zone argument to encode-universal-time, hence no
adjustment for daylight saving time was applied. However in your call
to decode-universal-time, you didn't supply an explicit time-zone
argument, so since your (implementations idea of your) current
time-zone has daylight savings time in effect, the hour was adjusted
accordingly.
Generally, I'd suggest either supplying time-zone arguments in both
calls, or in none of them.
Note that users whose (implementations idea of their) time-zone
doesn't have daylight savings time in effect at the present moment (or
ever) will not see the effect shown above. Ain't time grand?
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
"Pierre R. Mai" wrote:
>
> .... Ain't time grand?
Is it DST what you mean ? Yes, it continues to puzzle me.
Actually the question was inspired by (cmucl-18c):
* (parse-time "2001-05-15")
0: (ENCODE-UNIVERSAL-TIME 0 0 0 15 5 2001 -2)
0: ENCODE-UNIVERSAL-TIME returned 3198866400
Don't you think (E-U-T 0 0 0 15 5 2001) would be better ?
--
Vladimir Zolotykh