Hi,
The following function for checking the validity of the date/time
represented as decoded time (offered in the reply to some question
about dealing with dates by Eric Naggum) failes mysteriously (well the
mystery is the DST).
[I might have changed a letter or two in the function compared
to the original Naggum's version, In any case the changes are but
superficial. ]
(defun valid-date-p (&rest e-u-t-args)
(let* ((timezone (nthcdr 6 e-u-t-args))
(encoded (apply #'encode-universal-time e-u-t-args))
(decoded (multiple-value-list
(if timezone
(decode-universal-time encoded (car timezone))
(decode-universal-time encoded)))))
(if (equal (subseq e-u-t-args 0 6)
(subseq decoded 0 6))
encoded
nil)))
It returns NIL for 0 0 2 4 4 2004 (EEST or GMT +2 [-2 in CL]). Do you
think VALID-DATE-P is just to the poor date? And if it is not how to
vindicate the victim? Probably in Autumn something similar may also
take place.
Thanks in advance
--
Vladimir Zolotykh
Vladimir Zolotykh <······@eurocom.od.ua> writes:
> Hi,
>
> The following function for checking the validity of the date/time
> represented as decoded time (offered in the reply to some question
> about dealing with dates by Eric Naggum) failes mysteriously (well the
> mystery is the DST).
>
> [I might have changed a letter or two in the function compared
> to the original Naggum's version, In any case the changes are but
> superficial. ]
>
> (defun valid-date-p (&rest e-u-t-args)
> (let* ((timezone (nthcdr 6 e-u-t-args))
> (encoded (apply #'encode-universal-time e-u-t-args))
> (decoded (multiple-value-list
> (if timezone
> (decode-universal-time encoded (car timezone))
> (decode-universal-time encoded)))))
> (if (equal (subseq e-u-t-args 0 6)
> (subseq decoded 0 6))
> encoded
> nil)))
>
> It returns NIL for 0 0 2 4 4 2004 (EEST or GMT +2 [-2 in CL]). Do you
> think VALID-DATE-P is just to the poor date? And if it is not how to
> vindicate the victim? Probably in Autumn something similar may also
> take place.
What Lisp implementation are you using? I don't get NIL for
the arguments you mention in either CLISP or CMUCL. Perhaps
I'm misunderstanding: I'm calling (VALID-DATE-P 0 0 2 4 4 2004 -2).
I don't get NIL when I omit the final -2, either. I'm in timezone 0,
with DST currently in force.
DECODE-UNIVERSAL-TIME is specified to ignore daylight saving time
information when it's provided with a timezone, and when no timezone
is used ENCODE-UNIVERSAL-TIME and DECODE-UNIVERSAL-TIME should
be inverses.
What do you get for ...
(encode-universal-time 0 0 2 4 4 2004)
(encode-universal-time 0 0 2 4 4 2004 -2)
? Call those A and B; then what do you get for
(decode-universal-time A)
(decode-universal-time B -2)
?
--
Gareth McCaughan
.sig under construc
Vladimir Zolotykh <······@eurocom.od.ua> writes:
> The following function for checking the validity of the date/time
> represented as decoded time (offered in the reply to some question
> about dealing with dates by Eric Naggum) failes mysteriously (well the
> mystery is the DST).
>
[skipped]
>
> It returns NIL for 0 0 2 4 4 2004 (EEST or GMT +2 [-2 in CL]). Do you
> think VALID-DATE-P is just to the poor date? And if it is not how to
> vindicate the victim? Probably in Autumn something similar may also
> take place.
Using SBCL 0.8.8 Under linux I get:
* (decode-universal-time (encode-universal-time 0 0 2 4 4 2004))
0
0
1
4
4
2004
6
NIL
5
*
Showing one hour earlier, and this would cause valid-date-p to fail.
Due to the moving of the clocks ahead I don't think this time
exists. I goes from 01:59 to 03:00, so I think valid-date-p is
working correctly.
However when I tried the experiment with the CVS version of CLISP on
the same platform I got:
[2]> (decode-universal-time (encode-universal-time 0 0 2 4 4 2004))
0 ;
0 ;
3 ;
4 ;
4 ;
2004 ;
6 ;
T ;
5
[3]>
and it continued to be an hour off up till 07:00. This is seems to be
a bug in CLISP.
--
Barry Fishman
On Thu, 29 Apr 2004 21:54:30 GMT, Barry Fishman <·············@att.net>
wrote:
> Using SBCL 0.8.8 Under linux I get:
>
> * (decode-universal-time (encode-universal-time 0 0 2 4 4 2004))
>
> 0
> 0
> 1
> 4
> 4
> 2004
> 6
> NIL
> 5
>
> *
>
> Showing one hour earlier, and this would cause valid-date-p to fail.
> Due to the moving of the clocks ahead I don't think this time
> exists. I goes from 01:59 to 03:00, so I think valid-date-p is
> working correctly.
Yes, but only if you're located somewhere in the US
>
> However when I tried the experiment with the CVS version of CLISP on
> the same platform I got:
>
> [2]> (decode-universal-time (encode-universal-time 0 0 2 4 4 2004))
> 0 ;
> 0 ;
> 3 ;
> 4 ;
> 4 ;
> 2004 ;
> 6 ;
> T ;
> 5
> [3]>
>
> and it continued to be an hour off up till 07:00. This is seems to be
> a bug in CLISP.
>
I got the same in ACL:
cl-user(310): excl::*common-lisp-version*
"6.2 [Linux (x86)] (Apr 18, 2004 13:41)"
cl-user(311): (decode-universal-time (encode-universal-time 0 0 2 4 4
2004))
0
0
3
4
4
2004
6
t
-2
Well, the difficulty is that in the European Union (where myself
actually resides) summer time starts the last Sunday of March (not in
April as in the US) that is 28th of March this year. Hence there is no
missed hour in April. Furthermore, there are timestamps belonging to
that hour in April which I don't know how to process in CL and which
are stored by other software, PostreSQL for example.
--
Vladimir Zolotykh
Vladimir Zolotykh <······@eurocom.od.ua> writes:
> On Thu, 29 Apr 2004 21:54:30 GMT, Barry Fishman
> <·············@att.net> wrote:
>
>> Showing one hour earlier, and this would cause valid-date-p to fail.
>> Due to the moving of the clocks ahead I don't think this time
>> exists. I goes from 01:59 to 03:00, so I think valid-date-p is
>> working correctly.
>
> Yes, but only if you're located somewhere in the US
Oops.
> I got the same in ACL:
>
> cl-user(310): excl::*common-lisp-version*
> "6.2 [Linux (x86)] (Apr 18, 2004 13:41)"
> cl-user(311): (decode-universal-time (encode-universal-time 0 0 2 4 4
> 2004))
> 0
> 0
> 3
> 4
> 4
> 2004
> 6
> t
> -2
>
> Well, the difficulty is that in the European Union (where myself
> actually resides) summer time starts the last Sunday of March (not in
> April as in the US) that is 28th of March this year. Hence there is no
> missed hour in April. Furthermore, there are timestamps belonging to
> that hour in April which I don't know how to process in CL and which
> are stored by other software, PostreSQL for example.
When I set my timezone to eastern europe (I'm running SuSE Linux 9.0)
Running CMUCL 19e I get:
$ export TZ=Europe/Kiev
$ lisp
CMU Common Lisp 18e, running on ecube
With core: /home/util/cmucl-18e/lib/cmucl/lib/lisp.core
Dumped on: Thu, 2003-04-03 16:47:12+03:00 on orion
Send questions and bug reports to your local CMUCL maintainer,
or see <http://www.cons.org/cmucl/support.html>.
Loaded subsystems:
Python 1.1, target Intel x86
CLOS 18e (based on PCL September 16 92 PCL (f))
* (encode-universal-time 0 0 2 4 4 2004)
3290022000
* (decode-universal-time *)
0
0
2
4
4
2004
6
T
-2
*
If your encoded time value is 3290022000, the problem is probably in
just DECODE-UNIVERSAL-TIME, assuming your timezone info (T -2) is
correct.
The DECODE-UNIVERSAL-TIME and ENCODE-UNIVERSAL-TIME functions are
usually just Lisp functions, with some hook into the OS to get
timezone information. If you get the source to CMU Lisp, you will
find them in "src/code/time.lisp". You might be able to strip out the
source you need to supply a FIXED-DECODE-UNIVERSAL-TIME which you can
use. You would still need to write you own GET-TIMEZONE FFI to get
zone info from the OS, or supply your own timezone specific code.
--
Barry Fishman