I'm working with dates/times frequently.
At last I've made my mind to try the following.
Suppose the smallest granularity I need for some time
calculations is a day. Would be the benefit in that
case to use number of days since 1900-1-1 instead of
seconds ? If the least unit I need is a month that it worth
trying number of months. Converting usual dates like
2002-07-30 to number of days and vice versa doesn't seem
to be obvious task. Also for months. Would not it be simpler
to convert usual dates/times to CL universal times and than
universal time to number of days ?
Up to now the only I could think of is
(defconstant +secs/hour+ 3600)
(defconstant +secs/day+ #.(* 24 +secs/hour+))
(defun utime-to-days (utime)
(destructuring-bind (daylight-p zone)
(subseq (multiple-value-list (decode-universal-time utime)) 7)
(floor (+ +secs/day+ (- utime (* (if daylight-p
(1+ zone)
zone)
+secs/hour+)))
+secs/day+)))
But reverse seems much more difficult.
Could you give some hints here ? Which direction I should go ?
This is (almost) already part of the standard. Look up
encode-universal-time and decode-universal-time.
E.
In article <·················@eurocom.od.ua>, Vladimir Zolotykh
<······@eurocom.od.ua> wrote:
> I'm working with dates/times frequently.
> At last I've made my mind to try the following.
> Suppose the smallest granularity I need for some time
> calculations is a day. Would be the benefit in that
> case to use number of days since 1900-1-1 instead of
> seconds ? If the least unit I need is a month that it worth
> trying number of months. Converting usual dates like
> 2002-07-30 to number of days and vice versa doesn't seem
> to be obvious task. Also for months. Would not it be simpler
> to convert usual dates/times to CL universal times and than
> universal time to number of days ?
>
> Up to now the only I could think of is
>
> (defconstant +secs/hour+ 3600)
> (defconstant +secs/day+ #.(* 24 +secs/hour+))
>
> (defun utime-to-days (utime)
> (destructuring-bind (daylight-p zone)
> (subseq (multiple-value-list (decode-universal-time utime)) 7)
> (floor (+ +secs/day+ (- utime (* (if daylight-p
> (1+ zone)
> zone)
> +secs/hour+)))
> +secs/day+)))
>
> But reverse seems much more difficult.
>
> Could you give some hints here ? Which direction I should go ?
> (defconstant +secs/hour+ 3600)
> (defconstant +secs/day+ #.(* 24 +secs/hour+))
This is not necessarily true. Depending on how far in the future you
go, leap seconds may throw you off.
If you ignore this, you may want to base your times on noon instead of
midnight, so that a one-second change won't throw you off by a full
day.
You can look for a paper entitled "A Long, Drawn-Out History of Time",
and the Lisp library LOCAL-TIME it inspired, so you don't have to deal
with some of the problems it's dealt with already.
Or just use encode- and decode-universal time.
joelh
* Joel Ray Holveck
| You can look for a paper entitled "A Long, Drawn-Out History of Time",
| and the Lisp library LOCAL-TIME it inspired, so you don't have to deal
| with some of the problems it's dealt with already.
The paper's title is "The Long, Painful History of Time". You'll find it at
<http://naggum.no/lugm-time.html>. Another excellent suggestion is "A Brief
History of Time".
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
>> You can look for a paper entitled "A Long, Drawn-Out History of Time",
>> and the Lisp library LOCAL-TIME it inspired, so you don't have to deal
>> with some of the problems it's dealt with already.
> The paper's title is "The Long, Painful History of Time". You'll find it at
> <http://naggum.no/lugm-time.html>. Another excellent suggestion is "A Brief
> History of Time".
Thanks... Sorry about the mistake.
"Always... never... forget to check your references."
- Real Genius
Cheers,
joelh
Erik Naggum wrote:
>
> The paper's title is "The Long, Painful History of Time". You'll find it at
> <http://naggum.no/lugm-time.html>. Another excellent suggestion is "A Brief
> History of Time".
The latest LOCAL-TIME's source is at
cvs ··················@alpha.onshored.com:/cvs co local-time
Right ?
[I've tried http://sourcery.naggum.no/lisp/local-time.html. It was
not responding at the time of my trying.]
--
Vladimir Zolotykh
Joel Ray Holveck wrote:
>
> You can look for a paper entitled "A Long, Drawn-Out History of Time",
> and the Lisp library LOCAL-TIME it inspired, so you don't have to deal
> with some of the problems it's dealt with already.
Where is the LOCAL-TIME you've referenced to ? I've tried
LOCAL-TIME from alpha.onshored.com:/cvs. To almost all my
attempts to use timezone it answers
Error: not implemented.
--
Vladimir Zolotykh