From: Kelly Murray
Subject: Representing Time
Date: 
Message-ID: <36EC737C.22326BC4@IntelliMarket.Com>
I'd like to ask if anyone has any ideas on something that 
might be better than the current Universal Time of CL.

 It is an integer not a unique data type
 It can't represent time before Jan 1 1900 ("universal"?).
 It is a functional object which can't be mutated.
 The current value overflows a 29 bit fixnum.

What I use in my web server is to
increase the base time to  Jan 1, 1990, and to allow
negative numbers representing earlier dates.
This makes storing current dates in the OODB a "non-consing" 
operation for a long time, which is
quite useful for faster logging for example.

But I wonder if it is better to use a real object class
for a DATE and TIME and have methods which manipulate them,
and incur the consing but in exchange get a better representation.

Any opinions or proposals?

-Kelly Murray  ···@niclos.com

From: Howard R. Stearns
Subject: Re: Representing Time
Date: 
Message-ID: <36ED3C48.953269FB@elwood.com>
While I don't know the X3J13 decision process, I'd like to point out
that while it's easy enough to simply SAY that negative numbers reflect
time before 1900, it is NOT easy to have implementations do the right
thing for decoding a universal time encoded in this way:

  + Date's are all screwed up in the 1750's, assuming British dates.
  + Should timezone be used to figure out what (non-British) dating
system was 
    in use?
  + What about theoretical years -- i.e., years before the church
established a 
    particular year numbering? 
  + Is it meaningful to say that January 1, one million BC was Thursday?
  + ANSI ignores leap seconds.  Should they be ignored going back a
million years. 
    I wouldn't want to trust astronomical calculations computed this
way.
    For that matter, what about the movmenent of continents effecting
timezone?

Remember that ANSI is an American standard and does not try to deal with
other cultures.  To explicitly handle earlier times implicitly denotes
that you are intending to handle SOME set of other (i.e., earlier)
cultures.  You'd better be prepared to define the behavior of the system
in these terms.

Sam Steingold wrote:
> 
> >>>> In message <·················@IntelliMarket.Com>
> >>>> On the subject of "Representing Time"
> >>>> Sent on Sun, 14 Mar 1999 18:42:04 -0800
> >>>> Honorable Kelly Murray <···@IntelliMarket.Com> writes:
>  >> I'd like to ask if anyone has any ideas on something that
>  >> might be better than the current Universal Time of CL.
>  >>
>  >>  It is an integer not a unique data type
> 
> oh well.  the time line is an affine space (1-dimensional, over the
> reals), so it is quite meaningful to add a number to a time value.  IMO,
> replacing (+ current-time time-shift) with (advance-time current-time
> time-shift) is no improvement.
> 
>  >>  It can't represent time before Jan 1 1900 ("universal"?).
> 
> so make negative integers acceptable!  (IIUC, unsigned integers were
> used to make 32 bits enough for 1900-01-01 -- 2036-02-07)
> 
>  >>  It is a functional object which can't be mutated.
> 
> good!
> 
>  >>  The current value overflows a 29 bit fixnum.
> 
> so switch to a 64-bit platform with a bigger fixnum! :-)
> 
> time *is* a single real number (after you choose time zero), as a
> physical quantity, so the only question is whether integer is more
> appropriate than float etc.
> 
> --
> Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux
> Micros**t is not the answer.  Micros**t is a question, and the answer is Linux,
> (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
> Please wait, MS Windows are preparing the blue screen of death.
From: Marco Antoniotti
Subject: Re: Representing Time
Date: 
Message-ID: <lw90cy8xto.fsf@copernico.parades.rm.cnr.it>
"Howard R. Stearns" <······@elwood.com> writes:

> While I don't know the X3J13 decision process, I'd like to point out
> that while it's easy enough to simply SAY that negative numbers reflect
> time before 1900, it is NOT easy to have implementations do the right
> thing for decoding a universal time encoded in this way:
> 
>   + Date's are all screwed up in the 1750's, assuming British dates.
>   + Should timezone be used to figure out what (non-British) dating
> system was 
>     in use?
>   + What about theoretical years -- i.e., years before the church
> established a 
>     particular year numbering? 
>   + Is it meaningful to say that January 1, one million BC was Thursday?
>   + ANSI ignores leap seconds.  Should they be ignored going back a
> million years. 
>     I wouldn't want to trust astronomical calculations computed this
> way.
>     For that matter, what about the movmenent of continents effecting
> timezone?
> 
> Remember that ANSI is an American standard and does not try to deal with
> other cultures.  To explicitly handle earlier times implicitly denotes
> that you are intending to handle SOME set of other (i.e., earlier)
> cultures.  You'd better be prepared to define the behavior of the system
> in these terms.
> 

#+:NOISE-AHEAD

All of this makes me put forth the following two simple proposals:

1 - We should all revert to counting years "Ab Urbe Condita" (AUC),
    i.e. from 753 BC, year of Rome's foundation (apologies to people
    writing from India, China, Mexico and a handful of other places -
    after all I live in The Eternal City and must make this proposal :) )
    We would now be in year 2752 and we would have gotten rid of most
    of the Y2K problem. On top of that, separation of Church and State
    would be re-enforced: a thing always useful on the banks the Tiber river.

2 - or - as an alternative - we should finally switch to Stardates, of
    which, I am sure, somebody has well detailed spec. :)

As a nice extra goody, in the process, we should also throw down the
drain the Imperial system and its "furlongs". Let's have all those
bloody UK tabloids change their format to ISO A3! :)

Cheers


-- 
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it
From: Daniel Finster
Subject: Re: Representing Time
Date: 
Message-ID: <36ED742C.7F6D1761@nanofab.utdallas.edu>
Marco Antoniotti wrote:
>
> #+:NOISE-AHEAD
> 
> All of this makes me put forth the following two simple proposals:
> 
> 1 - We should all revert to counting years "Ab Urbe Condita" (AUC),
>     i.e. from 753 BC, year of Rome's foundation (apologies to people
>     writing from India, China, Mexico and a handful of other places -
>     after all I live in The Eternal City and must make this proposal :) )
>     We would now be in year 2752 and we would have gotten rid of most
>     of the Y2K problem. On top of that, separation of Church and State
>     would be re-enforced: a thing always useful on the banks the Tiber river.
> 
> 2 - or - as an alternative - we should finally switch to Stardates, of
>     which, I am sure, somebody has well detailed spec. :)

Instead of counting time by the Christian calander, which has relevance
only to Christians, or by the Roman calander, which has relevance only
to historians and neo-Empirists, or by Stardates, which have relevance
only to Trekkies, or by any other calander which only has relevance to a
sub-group of the population, I would like to propose the following:

Count time as the number of seconds (an international standard unit)
since the first detonation of an atomic bomb.  This has a few good
qualities: 

  1/ This time-system is relevant to all of humanity.  Whether you are
for atomic
     energy or against it (personally, I'm for it), you cannot deny that
this is 
     the single most important event in the history of the world.
  2/ This event was timed precisely, so we have an exact base from which
to do our
     calculations.
  3/ It sounds neat.  We are in the Atomic Age, we might as well live
it.
  4/ As Marco pointed out, the advantage of speration of Church and
State.
     Not just the Christian church, but any church as well as any 
     other belief-system (such as the abovementioned neo-Empirist
belief-system).

In addition, if we start rendering time using a metric scale
(kiloseconds, megaseconds, etc) instead of these archaic units such as
days and weeks, we no longer have to worry about leap-years,
leap-seconds, or any of that other dross.  Also, this would put our
macro-scale time renderings in the same consistent system that we
already use for micro-scale time renderings (microseconds, nanoseconds,
etc -- all currently completely standard time units).
From: Kent M Pitman
Subject: Re: Representing Time
Date: 
Message-ID: <sfwyakyjokq.fsf@world.std.com>
Daniel Finster <··@nanofab.utdallas.edu> writes:

> Count time as the number of seconds (an international standard unit)
> since the first detonation of an atomic bomb. [...] 
>   3/ It sounds neat.

Besides, I used to have a teacher who had a wristwatch that glowed in
the dark because (she said) it had radium.  She'd been told that
was bad and that she shouldn't wear it, but she really liked it and
wouldn't give it up.  At the time, I thought a radioactive watch
sounded neat.  As I got older, I decided things that sound neat don't
always sound neat.

>  We are in the Atomic Age, we might as well live it.

Uh... what about when the Atomic Age yields to the Consing Age?
Will we shift the base to the date John McCarthy first booted Lisp?
From: Pierre R. Mai
Subject: Re: Representing Time
Date: 
Message-ID: <87emmqb5lg.fsf@orion.dent.isdn.cs.tu-berlin.de>
Kent M Pitman <······@world.std.com> writes:

> >  We are in the Atomic Age, we might as well live it.
> 
> Uh... what about when the Atomic Age yields to the Consing Age?
> Will we shift the base to the date John McCarthy first booted Lisp?

And anyway, I'm always being told that we live now in the "Information 
Age" or something of the sort, so we should probably count from the
moment the first bit was split... ;->

-- 
Pierre Mai <····@acm.org>               http://home.pages.de/~trillian/
  "One smaller motivation which, in part, stems from altruism is Microsoft-
   bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
From: Marco Antoniotti
Subject: Re: Representing Time
Date: 
Message-ID: <lwogltbzpu.fsf@copernico.parades.rm.cnr.it>
Kent M Pitman <······@world.std.com> writes:

> Daniel Finster <··@nanofab.utdallas.edu> writes:
> 
	...
> 
> >  We are in the Atomic Age, we might as well live it.
> 
> Uh... what about when the Atomic Age yields to the Consing Age?
> Will we shift the base to the date John McCarthy first booted Lisp?
> 

Absolutely! When exactly was that?  Let's have the CONS-DATE!

Cheers

-- 
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it
From: Gareth McCaughan
Subject: Re: Representing Time
Date: 
Message-ID: <86k8whg4nx.fsf@g.pet.cam.ac.uk>
Daniel Finster wrote:

>   1/ This time-system is relevant to all of humanity.  Whether you are
>      for atomic energy or against it (personally, I'm for it), you
>      cannot deny that this is the single most important event in the
>      history of the world.

I deny it. So there. :-)

-- 
Gareth McCaughan       Dept. of Pure Mathematics & Mathematical Statistics,
·····@dpmms.cam.ac.uk  Cambridge University, England.
From: David Gadbois
Subject: Re: Representing Time
Date: 
Message-ID: <w0kiuc1fhjs.fsf@lagavulin.cyc.com>
For an in-depth look at hairy calendrical systems and how to deal with
them, check out the book "Calendrical Calculations" by Dershowitz and
Reingold ISBN 0-521-56474-3.  It even has Lisp (well, elisp) code!
There was a review in IEEE Annals of the History of Computing that
slammed it for historical reasons, but I found it perfectly usable for
background on how to do a DECODE-UNIVERSAL-TIME implementation.

E.g.:

(decode-universal-time (expt 2 100))
16
36 
10 
31 
10 
40170248388634916374580 
1 
NIL 
6 

No Y2K problems there.

--David Gadbois
From: Vassil Nikolov
Subject: Re: Repraesentatio Temporis
Date: 
Message-ID: <7ckpug$b6a$1@nnrp1.dejanews.com>
In articulo <··············@copernico.parades.rm.cnr.it>,
  Marcus Antoniottus <·······@copernico.parades.rm.cnr.it> scripsit:
(...)
> 1 - We should all revert to counting years "Ab Urbe Condita" (AUC),
>     i.e. from 753 BC, year of Rome's foundation (apologies to people
>     writing from India, China, Mexico and a handful of other places -
>     after all I live in The Eternal City and must make this proposal :) )
>     We would now be in year 2752 and we would have gotten rid of most
>     of the Y2K problem. On top of that, separation of Church and State
>     would be re-enforced: a thing always useful on the banks the Tiber river.

FAVEO

INSERDICA
ANTEDIEMSEPTIMVMDECIMVMCALENDASAPRILESANNOMMDCCLIIABVRBECONDITA

(Postridies idibus martiis anno domini MIM.)

(For the barbarians such as myself, this means that today is the
17th day before the Calends of April, year 2752 after the founding
of the City, or the day after the Ides of March the same year;
i.e., 16 March 1999.)

Sorry, couldn't resist.

Vale, Basilius.

Vassil Nikolov <········@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
   LEGEMANVALEMFVTVTVM  (Ancient Roman programmers' adage.)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    
From: Gareth McCaughan
Subject: Re: Repraesentatio Temporis
Date: 
Message-ID: <86hfrlg4ls.fsf@g.pet.cam.ac.uk>
Vassil Nikolov wrote:

>    LEGEMANVALEMFVTVTVM  (Ancient Roman programmers' adage.)

Shouldn't that be something like LEGEMANUALEMFUTUANTEM?
It's ...ing, not ...ed.

-- 
Gareth McCaughan       Dept. of Pure Mathematics & Mathematical Statistics,
·····@dpmms.cam.ac.uk  Cambridge University, England.
From: Harley Davis
Subject: Re: Repraesentatio Temporis
Date: 
Message-ID: <7cm5d6$l25$1@ffx2nh3.news.uu.net>
>Vassil Nikolov wrote:
>
>>    LEGEMANVALEMFVTVTVM  (Ancient Roman programmers' adage.)
>
>Shouldn't that be something like LEGEMANUALEMFUTUANTEM?
>It's ...ing, not ...ed.
>
>--
>Gareth McCaughan       Dept. of Pure Mathematics & Mathematical Statistics,
>·····@dpmms.cam.ac.uk  Cambridge University, England.

RTFG (G = Grammar) and you'd know...

;^)

-- Harley
From: Vassil Nikolov
Subject: Re: Repraesentatio Temporis
Date: 
Message-ID: <7cnkff$qie$1@nnrp1.dejanews.com>
In article <··············@g.pet.cam.ac.uk>,
  Gareth McCaughan <·····@dpmms.cam.ac.uk> wrote:
> Vassil Nikolov wrote:
>
> >    LEGEMANVALEMFVTVTVM  (Ancient Roman programmers' adage.)
>
> Shouldn't that be something like LEGEMANUALEMFUTUANTEM?
> It's ...ing, not ...ed.

I take it you mean `futuentem,' i.e. participium praesentis activi
(actually, the accusativus thereof).

Well, I thought that `fututus' (participium perfecti passivi)
matched the meaning (not the form) better in this particular
case.  Not being a native speaker, I may not have captured
the underlying grammatical substrate of `fucking' correctly
(moreover that in my mother language (Bulgarian) we use the
past participle for this phrase; but I don't want to
start a (psycho)linguistical debate).  So you might be right.

Any native Latin speakers out there?

Or, let me use this wonderful new and improved Common Lisp with
negative time:

> (with-universal-time (- (* 2000 365 24 3600))  ;2K years before time 0
    (grammar-check "LEGEMANVALEMFVTVTVM"))

Error: universal time is not defined for the epoch before
       G. Julius Caesar's reforms of the calendar.
:A abort
:C supply a different emperor

Good luck,
Vassil.

P.S.  The minus sign in (-1, 1, 1, 1) isn't there for nothing...

Vassil Nikolov <········@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
   LEGEMANVALEMFVTVTVM  (Ancient Roman programmers' adage.)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    
From: Raymond Wiker
Subject: Re: Representing Time
Date: 
Message-ID: <87sob7dngy.fsf@foobar.arendal.orion.no>
Kelly Murray <···@IntelliMarket.Com> writes:
> I'd like to ask if anyone has any ideas on something that 
> might be better than the current Universal Time of CL.
> 
>  It is an integer not a unique data type
>  It can't represent time before Jan 1 1900 ("universal"?).
>  It is a functional object which can't be mutated.
>  The current value overflows a 29 bit fixnum.
> 
> What I use in my web server is to
> increase the base time to  Jan 1, 1990, and to allow
> negative numbers representing earlier dates.
> This makes storing current dates in the OODB a "non-consing" 
> operation for a long time, which is
> quite useful for faster logging for example.
> 
> But I wonder if it is better to use a real object class
> for a DATE and TIME and have methods which manipulate them,
> and incur the consing but in exchange get a better representation.
> 
> Any opinions or proposals?

        I've just done something similar for C++. I decided to create
a class that encapsulates a time_t (in most implementations, a signed
32-bit value that represents an offset in seconds from Jan 1st,
1970). I addition, I included a field in the class for holding a
pointer to a "struct tm", which is the "exploded view" of the time_t
value. The time_t pointer is used as a cache; it's invalidated
whenever the time_t changes, and set up as needed.

        The main advantages of this design are (in my opinion):

        - builds on the ANSI C library, and so should be portable
(except the Microsoft platform, which does not appear to be portable
in the usual meaning of the word)

        - uses well-known and stable code for all the difficult things 
(well, most of them, anyway. I had to add some code of my own for
extracting the week number and year for a given time, and also a
conversion in the opposite direction)

        - arithmetic operations on dates use the time_t member
variable, and eventually results in inline integer operations.

        - when (if?) the system/compiler vendors switch to a 64-bit
time_t, my class will automatically take advantage of the wider range
(except possibly some minor adjustment if the 64-bit value has
sub-second accuracy)

        - support for time zones, leap seconds etc *should* drop in
for free (again, with reservations about the Microsoft platform).

        I have thought about something similar for Lisp; I think it
would make sense, and carry the same advantages as the C++ case. Note
that Kelly's idea of moving the pivot point to Jan 1st, 1990 could be 
trivially accommodated.

        //Raymond.

-- 
Raymond Wiker, Orion Systems AS
+47 370 61150
From: Tim Bradshaw
Subject: Re: Representing Time
Date: 
Message-ID: <nkjemmqpx5k.fsf@tfeb.org>
Sam Steingold <···@goems.com> writes:
> 
> time *is* a single real number (after you choose time zero), as a
> physical quantity, so the only question is whether integer is more
> appropriate than float etc.
> 

Integers are better, because if you choose a float repn you end up
with varying precisions as you get further from t_0, which is not
usually what you want, unless you are doing physics or something in
which case you probably aren't using the provided repn anyway.

(Actually, for CL, *rationals* are probably better.)
From: Kent M Pitman
Subject: Re: Representing Time
Date: 
Message-ID: <sfwzp5eboxe.fsf@world.std.com>
Tim Bradshaw <···@tfeb.org> writes:

> Sam Steingold <···@goems.com> writes:
> > 
> > time *is* a single real number (after you choose time zero)
> 
> Integers are better,

I'm going to disagree with both of these.  I suggest a structured
object, not an integer, unless efficiency is so paramount as to 
override correctness.  (I have to assume it's not, or the question
wouldn't be getting askd.)

To begin to understand the correctness of a representation, we should
explore its edges.   Just as we can "understand" fixnums' limitations
by exploring "fixnum overflow" and moving toward biguns, my understanding
of time is informed by places where my representation of time reaches its
edges.

Leap seconds are what bother me the most.  The fact that politically
an organizational body can insert an extra second between two times
means that any representation of a future time is virtually, not
actually, correlated to the calendar.  If you pick the time for
1-Jan-2000 (which is in the future at the time I write this; time has
a habit of not standing still, so archival of messages like this is
problematic for later readers), and then store the appropriate integer
in a file, but then someone inserts a leap second, the computer
community is in a quandary.  In general, we computer folk, the
supposed guardians of informational and representational integrity for
the world, just fudge and say "oh, this representation doesn't
accomodate leap seconds". But that's a little like saying pi is 22/7
or 3.14 We use what's available, but we shouldn't confuse ourselves
into thinking that just because we may use a rational or a float to
represent a real that it is in fact a real.  Ditto we shouldn't assume
that because we use integer offsets from a point in time to represent
time that this is in fact a good metric of time.

Multiple calendar systems are a related phenomenon.  You might say that the
whole point of an integer is to avoid this, but you're assuming that avoidance
is best decided "in advance" (at datatype design time) rather than after
(at datatype consulation/reference time).  In fact, when we see a date in
an alternate calendar system, we need to know there is a problem of ambiguity
and we may want to represent the ambiguity.  For example, "today at noon"
is a bad time for me to tell us all on this newsgroup to get together even
though if we have time parsers we can all parse that.  If you can imagine
a problem to debug the problem of everyone inferring different timezones,
you're stuck with the problem of understanding the thing as text (yuck)
or understanding it as an integer (not ambiguous).  To write a program that
"gets the joke" you have to have a program that can embrace the notion of
the ambiguity "as data".  A type that accomodates (as pathnames do)
"part of a representation" but that, for example, won't let you do certain
operations unless all the slots are filled would be very useful. [It's hard
for me to push this analogy too far without noting that I think it's a
tactical error that you can't make a pathname with no host component in
conforming ANSI CL--the implementation must supply a host--which means you
can't reason about pathnames where you know the name and type but not the
host, which thwarts cross-host file defaulting.  I complained about this
at X3J13 and some (led by Moon, as I recall) said it was useless to have
a hostless pathname because you couldn't coerce it to a namestring; I would
have said it was useful to have one because there were operations you could
do but that coercion to a namestring should not be one of them.]

I think having a time that is only partially specified or specified by
wildcards would be quite useful.  Having to invent a separate datatype
for "Aug 1999" because times are fully specified is sad.  So add
wildcards and ranges to the list of things that are at the edges of
what I can do with an integer.  Also, things like "Tuesday" are
ambiguous not just for lack of specification but because even while
they are useful, you need to know if past-only, future-only, or both
is possible.  People know these things, and a time could carry that
bit of context (the base time against which it is parsed) without
merging it.  Other times have additional characteristics such as "my
birthday".  The Lisp mahcine time parser can parse things like "three
days after my birthday" but it has a problem that it makes an
alternate choice between "my birthday this year" vs "my birthday the
year I was born".  Again, this is resolved by context by humans.

Precision is yet another issue that could be represented in time.  When I
say "I did this in march 1999", I am not saying "I did this between 
12:00:00 GMT (or some unspecified tz) Mar 1 1999" and the same time the
next month.  Sometimes I am.  But if I'm examining a cable television
schedule the boundary time might be different.  I'm being approximate in
various ways.  I might even be just misremembering.  People remember
the words spoken to idiot-check their translation to a more precise
representation in case the representation fails.  And anyone who has ever
set a system clock and didn't have access to an atomic clock on a 
reliable-speed data connection knows they end up lying about the time.
They look at their wristwatch and guess.  So the precision in which 
a program uses to get panicked about a certain time being in the past if
the time is on a file date of a file date created on another computer 
is a reason for program bugs, but shouldn't be.  It should carry
proper annotation to avoid the confusion, via pedigree.
I won't get into the issue of time lapse between a reliable source
and two observing listeners to that source, but that's obviously in there,
just maasked by the fact that we don't offer enough time precision in our
typical machine clock to capture it.  Some day we might.

The other "obvious" issue is relativity, and I won't say much about it
but you can see the obvious issues there as well for using a single
integer.  An inertial pedigree is also needed in the most general
case, I suspect.  I did read a book about relativity once a long time
ago, though, when I was little, that said that some native americans
didn't have the notion of "simultaneity".  The author was suggesting
that this was not an accident or impoverished situation but a
sophisticated observation that it is virtually meaningless to say that
"fred walked a day and then did something at the same time as joe"
given no cues about how the two timelines relate.  Even if they yell
"at the same time", Joe can think he yelled first and Fred can think
he did.  They don't share a common reality.  It's a nice experiment
because it doesn't require fancy tools to measure the speed of
light--you can observe a discrepancy in time between light and sound,
but if you don't realize that's what's going on (speed difference),
you'll assume the two people just saw a different time ordering.  You
can claim the problem is "fixed" by saying what really happened, but
you still have a bubble in the perceptual space becuase it really is
true that there is no single party (not the light, not fred, not joe)
which lays claim to a unique right to use the word "now" or "before"
or "after".  And in practice, a great many situations (even just DejaNews,
trying to get post order right) have this same problem of simultaneity.
Representing time in a way that accomodates this information is more
useful, I claim, than representing it in a way that denies it.
This problem also comes up in communication with spacecraft, some of
which I understand have Lisp on board...
Go to http://www.jpl.nasa.gov/galileo/
and read the second-by-second countdown to see the problem.  Yes, it's
5 minutes away whether in this timezone or that, but is the five minutes
measured on earth or at the space probe?  (They tell you, but it's surely
not captured in "time represented as an integer").

Well, that's a hint of why I don't like integers for time...  They may
have gotten us past Y2K, and they're good for an engineering need of
fast, non-consing time, the next step up from counting machine clock
ticks.  But they are not a representation for the ages.  I'd compare
them to HTML.  HTML is likely not a representation of text for the
ages, but historians will be happy to have it because weak as it is,
it's well-understood and so are its limitations.  In the future, HTML
will probably be replaced, but it will at least be easy for
archaelogists to puzzle out what it was about.  So HTML suffices for
now, subject to the caveat that you understand it's got built-in
limits that are doomed to one day be stressed.  Probably the same is
true of integer time.  I think programmers should use the CL
facilities; they're of high quality.  But we can do better for the
future.  If we want a shot at still being the representation of choice
when they're pawing through our dust, we need a sturdier set of
properties.
From: Espen Vestre
Subject: Re: Representing Time
Date: 
Message-ID: <w6vhg1x0je.fsf@wallace.nextel.no>
Kent M Pitman <······@world.std.com> writes:

> Precision is yet another issue that could be represented in time.  When I
> say "I did this in march 1999", I am not saying "I did this between 
> 12:00:00 GMT (or some unspecified tz) Mar 1 1999" and the same time the
> next month.  

just a few words from someone who has a background from computational
semantics research:  Most current semantic theories usually has a
fairly complex model theory for time, a simple "timeline" isn't even
close to the needs.  The base of even the most simple-minded theories 
of time is usually _intervals_ (I've been away from this for four years, 
so there might be some very exiting new theories that I'm not aware of...), 
not points.

Just consider all the temporal forms of verbs that occur in natural
languages, and how they map to time... (and remember the joke in
"the hitchhikers guide to the universe": Time travel was prohibited
because it made _talking_ about time so difficult ;-)).

If you think this is irrelevant, think again.  While not all of
us is hunting for the holy grail of artificial intelligence, we
may stumble upon the needs for semantically adequate models even
in relatively down-to-earth applications.

-- 

  espen
From: Tim Bradshaw
Subject: Re: Representing Time
Date: 
Message-ID: <nkj6781ljcx.fsf@tfeb.org>
Espen Vestre <··@nextel.no> writes:

> If you think this is irrelevant, think again.  While not all of
> us is hunting for the holy grail of artificial intelligence, we
> may stumble upon the needs for semantically adequate models even
> in relatively down-to-earth applications.
> 

I agree, but I don't think that necesarily a reason to push some
seriously hairy time representation into the language definiton.

It's a bit like the argument against banning fox hunting (Oh God, this
is going to bring out awfulnes isn't it, I apologise in advance, and
please don't assume anything about my attitude to anything but Lisp
from this):

	Fox hunting is awful, yes;
	But there are other awfuler things;
	And we have finite time right now to deal with everything,
		and dealing with it is very hard because there are complex
		issues;
	So, let's deal with the real big stuff first, 
		and get back to this when we have time.

I think for this kind of thing the argument is:

	CL's time representation, is adequate for simple things
		(in particular it doesn't have y2k problems);
	A simple extension (signed integers) would improve it a lot;
	We really want to be able to do really more complex stuff;
	But that is probably a *lot* more complex, and there will be a
		*lot* of argument about what is needed, both from the AI
		types, and from physicists (like me..);
	This would take a lot of time;
	And meantime we don't have time to get some more useful
		thing into the language, so C kills us;
	So, let's deal with the more urgent stuff first, and then get
		back to this when we have time.

--tim
From: Espen Vestre
Subject: Re: Representing Time
Date: 
Message-ID: <w6aexdwpbq.fsf@wallace.nextel.no>
Tim Bradshaw <···@tfeb.org> writes:

> I agree, but I don't think that necesarily a reason to push some
> seriously hairy time representation into the language definiton.

No, in fact, the high complexity of the matter is a good reason
*not* to push a *particular* hairy time representation into the 
language definition.

> 	A simple extension (signed integers) would improve it a lot;

oh yes!

-- 

  espen
From: Kent M Pitman
Subject: Re: Representing Time
Date: 
Message-ID: <sfwyakxmsul.fsf@world.std.com>
Espen Vestre <··@nextel.no> writes:

> Tim Bradshaw <···@tfeb.org> writes:
> 
> > I agree, but I don't think that necesarily a reason to push some
> > seriously hairy time representation into the language definiton.
> 
> No, in fact, the high complexity of the matter is a good reason
> *not* to push a *particular* hairy time representation into the 
> language definition.

I think even the existing integer representation is fully adequate to
compete with other languages. All of my remarks on this were predicated
on that.

CL already has three representations for time, and I don't think it
would be hurt by a fourth EXCEPT in that even having this discussion
takes away from other things we might do that are more competitive.

On the other hand, part of what makes Lisp great is that talking about
it is not just a discussion of meaningless bits, but often a metaphor
for discussing the world.  Here we discuss the time datatype, but we
are really just discussing the domain of the world we live in, and its
most precious of all commodities--time.  Talking about time is useful
because its study informs how we prejudice our views of the world by
shoehorning our understanding of the world into models that suit our
datatypes, a practice we engage in even if we never actually program
with those datatypes.

I program to improve my understanding of the world, and I study and
design programming languages to improve my understanding of how I
think about the world.

In fact, though, CL really doesn't probably need a fourth type of time
if it would just repair one if its existing ones: rather than think
about this as a replacement for universal time, we should perhaps
think of it as a replacement for "decoded time".  Decoded time would
be easier to carry around as a singl object (and harder to decode
using destructuring-bind :-).  If decoded times were like structures,
it would be easier to put NIL's, :WILD's, etc.  If it were made 
subclassable, users could experiment with other parts of its nature.
Just a thought...

> > 	A simple extension (signed integers) would improve it a lot;
> 
> oh yes!

I have a vague recollection that someone "solved" the problem in CLTL1
by using large timezones. Heh... For a suitably large timezone, the
present range of integers for time is completely adequate.  This, I
think, is one reason we came to add the restriction on time zones that
appears in ANSI CL, killjoys that we language designers were...
From: Kelly Murray
Subject: Re: Representing Time
Date: 
Message-ID: <36EEC6C2.333A5408@IntelliMarket.Com>
I think a couple points should be made.

Having multiple representations is simply a source of complexity
that makes it more difficult to document and learn the language,
and therefore I think it's best to have something that is
more complete and useful than just UT.

The problem with the current Universal-Time (UT) is that it conses
because of the 1900 starting date, which as far as I can see
has no particular value to it.  The 1970 date
of Unix was better.  I think 2000 is probably the best New choice
if negative numbers are allowed for early dates, at least
in current CL's, that is valid back to 1900.

I think Kent makes an important point in that it isn't possible
to specify "unknowns", or "don't cares" for a date.
I think in particular there is a natural distinction between
a DAY and the Time within a DAY, and UT is not great
for this case, and in particular it caused me hours of debugging
because adding 24 hours of seconds to a date doesn't always
get you the next day.

There is also lots of additional overhead in decoding the times
when you don't care about all the values, which may be unimportant
in todays 500Mhz CPU world, though I do think about PalmTops that
have much less CPU power and deal with dates heavily.

But one key feature missing from a UT is the ability to
define methods for it, particular to format the time
into a string representation.  I would find it most useful
to be able to define methods for date formating,
that could be extended or subclassed.

Let me throw out an outline suggestion for comment.
Have a class called DAY that has two implementation fields,
a DATE and TIME.  

(class day ()
 (date  :initform (current-date))
 (time  :initform (current-day-time))
 )
 
Where (current-date) is a integer formatted with bit-fields
for 3-bit timezone?, 4-bit-month, 5-bit day-of-month,
and the upper bits are the 11+ year value.
   11+      4     5   3
[..year][month][day][tz]    

In fact, this representation might be unspecified, 
and only accessor functions.

and (current-day-time) 
The Time is simply a seconds value, (* 24 60 60) = 86400 = 17 bits.
One might consider allow for more granularity, though probably
an unneeded complication.

Then one could have defined methods that could efficiently 
return string values for the numerical fields,
and still more defined methods for formating the day
which are defined to call certain methods.

-Kelly Murray   ···@niclos.com









Kent M Pitman wrote:
> 
> Espen Vestre <··@nextel.no> writes:
> 
> > Tim Bradshaw <···@tfeb.org> writes:
> >
> > > I agree, but I don't think that necesarily a reason to push some
> > > seriously hairy time representation into the language definiton.
> >
> > No, in fact, the high complexity of the matter is a good reason
> > *not* to push a *particular* hairy time representation into the
> > language definition.
> 
> I think even the existing integer representation is fully adequate to
> compete with other languages. All of my remarks on this were predicated
> on that.
> 
> CL already has three representations for time, and I don't think it
> would be hurt by a fourth EXCEPT in that even having this discussion
> takes away from other things we might do that are more competitive.
> 
> On the other hand, part of what makes Lisp great is that talking about
> it is not just a discussion of meaningless bits, but often a metaphor
> for discussing the world.  Here we discuss the time datatype, but we
> are really just discussing the domain of the world we live in, and its
> most precious of all commodities--time.  Talking about time is useful
> because its study informs how we prejudice our views of the world by
> shoehorning our understanding of the world into models that suit our
> datatypes, a practice we engage in even if we never actually program
> with those datatypes.
> 
> I program to improve my understanding of the world, and I study and
> design programming languages to improve my understanding of how I
> think about the world.
> 
> In fact, though, CL really doesn't probably need a fourth type of time
> if it would just repair one if its existing ones: rather than think
> about this as a replacement for universal time, we should perhaps
> think of it as a replacement for "decoded time".  Decoded time would
> be easier to carry around as a singl object (and harder to decode
> using destructuring-bind :-).  If decoded times were like structures,
> it would be easier to put NIL's, :WILD's, etc.  If it were made
> subclassable, users could experiment with other parts of its nature.
> Just a thought...
> 
> > >     A simple extension (signed integers) would improve it a lot;
> >
> > oh yes!
> 
> I have a vague recollection that someone "solved" the problem in CLTL1
> by using large timezones. Heh... For a suitably large timezone, the
> present range of integers for time is completely adequate.  This, I
> think, is one reason we came to add the restriction on time zones that
> appears in ANSI CL, killjoys that we language designers were...
From: Tim Bradshaw
Subject: Re: Representing Time
Date: 
Message-ID: <nkjn21d1lc2.fsf@tfeb.org>
Kent M Pitman <······@world.std.com> writes:

> I program to improve my understanding of the world, and I study and
> design programming languages to improve my understanding of how I
> think about the world.
> 

I think this is a brilliant summary of why Lisp is such a wonderful
language: it helps you think about the world rather than fight
endlessly against the language, either because it's just hard (C,
perl) or because it has such an attitude (prolog, perl, possibly
functional languages).

--tim
From: Rolf-Thomas Happe
Subject: Re: Representing Time
Date: 
Message-ID: <r5sob5ik16.fsf@leonce.mathematik.uni-freiburg.de>
In article <···············@world.std.com> Kent M Pitman writes:
   Leap seconds are what bother me the most.  The fact that politically
   an organizational body can insert an extra second between two times

There is a German amateur historian who holds that the "dark ages",
roughly the years 400-800, have been faked into the calendar by the
medieval Roman church.  Mere seconds are not that bothersome.

rthappe
From: Rob Warnock
Subject: Re: Representing Time
Date: 
Message-ID: <7cpuju$els5s@fido.engr.sgi.com>
Kent M Pitman  <······@world.std.com> wrote:
+---------------
| Leap seconds are what bother me the most.  The fact that politically
| an organizational body can insert an extra second between two times
| means that any representation of a future time is virtually, not
| actually, correlated to the calendar.
+---------------

Are you sure you're not talking about Daylight Savings Time instead of
leap seconds?  Except for the one discontinuity in 1972 when everyone
switched to UTC (Coordinated Universal Time) -- which *did* require
"political" agreement among a bunch of nations -- leap seconds are only
added as needed to keep "noon" within a second of noon, especially when
*non*-periodic (and therefore unpredictable by direct extrapolation *or*
political bodies!) variations in the rotation in the Earth occur. And
they're only added (or removed, but so far none have been) at midnight
December 31st or June 30th, so a fairly small vector of (4 bits/year
since 1972) can be used to adjust.

Note: I'm not sure how far in the future they can reliably predict when
leap seconds will have to be inserted. Maybe the following URLs will help:

	http://bul.eecs.umich.edu/uffc/fc_utc.html
	http://www.boulder.nist.gov/timefreq/faq/faq.htm#8
	http://www.gfy.ku.dk/~iag/iers95.txt
	http://www.grdl.noaa.gov/GRD/GPS/DOC/arc/leap.html

Looking at this last one, it's pretty clear that the insertion rate of
leap seconds is *not* a simple periodic function...


-Rob

-----
Rob Warnock, 8L-855		····@sgi.com
Applied Networking		http://reality.sgi.com/rpw3/
Silicon Graphics, Inc.		Phone: 650-933-1673
2011 N. Shoreline Blvd.		FAX: 650-964-0811
Mountain View, CA  94043	PP-ASEL-IA
From: Kent M Pitman
Subject: Re: Representing Time
Date: 
Message-ID: <sfw677zcnkv.fsf@world.std.com>
····@rigden.engr.sgi.com (Rob Warnock) writes:

> Kent M Pitman  <······@world.std.com> wrote:
> +---------------
> | Leap seconds are what bother me the most.  The fact that politically
> | an organizational body can insert an extra second between two times
> | means that any representation of a future time is virtually, not
> | actually, correlated to the calendar.
> +---------------
> 
> Are you sure you're not talking about Daylight Savings Time instead of
> leap seconds?  Except for the one discontinuity in 1972 when everyone
> switched to UTC (Coordinated Universal Time) -- which *did* require
> "political" agreement among a bunch of nations -- leap seconds are only [...]

You probably misunderstood what I meant by political.  In this limited
case, "science" and "politics" are both the same.  They are the enemy of
"mathematics" and "definition" in this very limited context.  In particular,
I decide I want to set off fireworks at midnight of the year 2000.  So
I do
 (encode-universal-time 0 0 0 1 1 2000)
 => 3155691600

Now what happens?  The earth gets sluggish and someone adds a leap
second.  That is the effect I'm calling political in that it is not
mathematical.  Think of my remarks as portraying the Earth as
intentionally meddling in an otherwise clean system.  It gets whimsy
and we all pay.  I *thought* I could assume that universal time was a
measure of time since 1970, but really it's not.  Because we don't add
in the leap seconds in universal time.  If we did, then my fireworks
would go off at 1 second before midnight because midnight of that date
is now at 3155691601, not 3155691600.  Indeed, it's probably worse
because several leap seconds have already happened, so they occur in
the interval since 1970 and so the appointed date is more like
3155691607 or some such thing. (Not sure the exact count.)

In practice, universal time is a measure of the THEORETICAL time between
1970 and now, not the ACTUAL time since everyone I know ignores those.
It would be virtually impossible not to, since we provide no way of informing
any database when they have occurred and a conforming Lisp doesn't come
with the necessary hardware to notice the slowing of the earth and to guess
that probably a leap second was added.  (Also, it *is* political when to
add the second, since the slowing is something that is happening 
continuously, not at the point of time the second is added.)

Daylight time is not a problem, by contrast, because machines largely
can be programmed to anticipate the occurrence of daylight time.

But I admit it's subject to some personal interpretation.
From: Howard R. Stearns
Subject: Re: Representing Time
Date: 
Message-ID: <36F11E29.A816E2A@elwood.com>
Kent M Pitman wrote:
> ...
> Daylight time is not a problem, by contrast, because machines largely
> can be programmed to anticipate the occurrence of daylight time.

Is it true that there is no computable date on which daylight savings
takes effect in Britain each year?  I think I read somewhere that each
year, Parliament must vote on when the changes take place, and that it
doesn't follow a set pattern.

If this is true, how do British operating systems deal with this issue? 
Must computer administrators program in the dates each year, and are
future time computations considered "tentative" in some way?
From: Tim Bradshaw
Subject: Re: Representing Time
Date: 
Message-ID: <nkjvhfy6a1y.fsf@tfeb.org>
"Howard R. Stearns" <······@elwood.com> writes:

> Is it true that there is no computable date on which daylight savings
> takes effect in Britain each year?  I think I read somewhere that each
> year, Parliament must vote on when the changes take place, and that it
> doesn't follow a set pattern.

Of course.  Anything else would not be democratic.

> If this is true, how do British operating systems deal with this issue? 
> Must computer administrators program in the dates each year, and are
> future time computations considered "tentative" in some way?

All British operating systems come with shortwave wirelesses which are
tuned to the world service.  A subsystem within the OS listens to the
hourly time signals, and synchronises the system appropriately.  The
administrator is only responsible for ensuring the valves in the
wireless are changed once or twice a year (this duty is conventionally
performed by the butler in large establisments).

(Seriously: yes, it was true, I remember patches for various Unixen to
deal with the date change.  I think it is now on a standard day,
although there is ongoing discussion about changing things so we are
on the same time as most of Europe).

--tim (in Britain)
From: Espen Vestre
Subject: Re: Representing Time
Date: 
Message-ID: <w61zimoipu.fsf@wallace.nextel.no>
Tim Bradshaw <···@tfeb.org> writes:

> (Seriously: yes, it was true, I remember patches for various Unixen to
> deal with the date change.  I think it is now on a standard day,
> although there is ongoing discussion about changing things so we are
> on the same time as most of Europe).

I thought the change of the end-date of the DST from the last sunday in
september to the last sunday in october was made in order to make it 
appear as if you had some influence on the EU.

Late october mornings are very dark up here, so we (and the Scots
as well, I would guess?) hate you for that ;-)

(oh yes... I remember that we discovered that not all unix installations
 had been patched in time... was it in 1996?)

-- 

  espen
From: Christopher C Stacy
Subject: Re: Representing Time
Date: 
Message-ID: <x8laexaot7c.fsf@world.std.com>
SI:%ADJUST-PLANETARY-ROTATION
From: Rob Warnock
Subject: Re: Representing Time
Date: 
Message-ID: <7csevv$eue5o@fido.engr.sgi.com>
Kent M Pitman  <······@world.std.com> wrote:
+---------------
| ...a conforming Lisp doesn't come with the necessary hardware to notice
| the slowing of the earth and to guess that probably a leap second was added.
+---------------

Is that a defect of the physical Earth, or of the politics which defined
a "conforming Lisp"?  ;-}  [Sorry, couldn't resist!]

+---------------
| (Also, it *is* political when to add the second, since the slowing is
| something that is happening continuously, not at the point of time the
| second is added.)
+---------------

Actually, not quite. If the Earth's rotation were *predictable*, they could
set up a formula similar to the leap year formula that said "add leap seconds
*here*", and we could all write it into our time library codes (and our
definitions of software "conformance") the way we do the leap year adjustments.

But in fact (mainly due to somewhat chaotic variations in the circulation
of the molten iron core deep inside), the Earth's rotation *doesn't* seem
to be very predictable, at least, not at the fine-grain needed for choosing
leap seconds.  So what they do is *measure* the rate, and when the discrepancy
between the rotation and "atomic time" gets "large enough" (by some rules
that were written down when Coordinated Universal Time was defined by the
ITU in 1970), they schedule a leap second at the next standard opportunity
(June or December) so that the difference bewteen UTC (cesium beam atomic
clock mean time) and UT1 (Earth rotation time) never exceeds 9/10'ths of
a second.

So, yes, again, there was politics involved when Coordinated Universal Time
was set up in 1970, but since then they've just "turned the crank" on the
rules for adding leap seconds. By which I mean, no *new* politics (which
is what your statement implied to me) is currently involved in deciding
when to add a leap second.

+---------------
| Daylight time is not a problem, by contrast, because machines largely
| can be programmed to anticipate the occurrence of daylight time.
+---------------

And if your machine *did* have equipment for measuring the Earth's rotation
(say, an automatic star-tracker) and if it had the "rules for adding a leap
second" [set in 1970] programmed into it, it could anticipate the need for
a leap second as well as the ITU and the "UTC" consortium... but unfortunately
neither can anticipate the future need for a leap second very well! This
old Earth just ain't very cooperative!


-Rob

p.s. Imagine if the variation in the Earth's rotation were several orders
of magnitude higher, e.g., so that the number of days in a year were a
random variable with a mean of 365.24 but a standard deviation of, say,
3 or 4 *days* (instead of the current SD of less than a second). How might
*that* affect our notion of computing with "time" (not to mention social
issues)?  [Hmmm... Sounds like an idea for a science-fiction novel in there
somewhere...]

If abyone can think of a good solution for *that* problem, it would probably
work even better for our actual current situation.

-----
Rob Warnock, 8L-855		····@sgi.com
Applied Networking		http://reality.sgi.com/rpw3/
Silicon Graphics, Inc.		Phone: 650-933-1673
2011 N. Shoreline Blvd.		FAX: 650-964-0811
Mountain View, CA  94043	PP-ASEL-IA
From: Kelly Murray
Subject: Re: Representing Time
Date: 
Message-ID: <36F1CBC7.4A23931D@IntelliMarket.Com>
I didn't see my last post on this appear, I think I might have
just sent it to Kent...  If you didn't see it, this version
is nicer.. ;)

In any case, my thoughts are to have two functions
that return a non-consing integer time value, (current-date)
and (current-time), which seperates a date from the time within
the date.  (current-time) is a millisecond timer that rolls
back to zero at the start of each day, which might only
be "required" to be accurate to one second.

(current-date) is an integer with bit fields for the numeric
day, month, year, and timezone, structured such that the
year field is the highest bits and thus can expand past a fixed
field (e.q. 9999) yeilding a bignum at some point, and years before
0 can also be represented as negatives (have to verify that).

Then have a function to extract the components from the (current-date)
value, (decode-date (current-date)) -> year, month, day, tz
with zero values indicating "don't care",
except for the year, maybe -1 is really zero
(though perhaps make Year 0 non-existing would appease the
non-christians...  Actually is there a Year Zero??  ;)

Then there is an class DAY that has these two fields:

(class day ()
 (date :initform (current-date))
 (time :initform (current-time))
 )
 
And then one can define methods to format the time.
A nil time value in the object could mean "don't care".

(method day-month ((d day))
 (aref '("" "Jan" "Fed" ..) (date-month (day.date d))))

(method http-date-850 ((d day))
 (format nil "~..." (day-month d) ...)

I think this is very flexible and efficient.
This can make logging more efficient since logs could
be grouped by the day, and only the (current-time)
would need to be recorded for each log.
As well, if only a date is needed, just (current-date)
could be used.  Only if both date and time are needed
would an allocated structure be required.
A function to convert the two integer values to
a CommonLisp UT shouldn't be difficult to write.

Then methods could be defined (and subclassed) to
generate string representations from the value.

This is my current thinking for NiCLOS.  Any comments appreciated.

-Kelly Murray    ···@niclos.com


Rob Warnock wrote:
> 
> Kent M Pitman  <······@world.std.com> wrote:
> +---------------
> | ...a conforming Lisp doesn't come with the necessary hardware to notice
> | the slowing of the earth and to guess that probably a leap second was added.
> +---------------
> 
> Is that a defect of the physical Earth, or of the politics which defined
> a "conforming Lisp"?  ;-}  [Sorry, couldn't resist!]
> 
> +---------------
> | (Also, it *is* political when to add the second, since the slowing is
> | something that is happening continuously, not at the point of time the
> | second is added.)
> +---------------
> 
> Actually, not quite. If the Earth's rotation were *predictable*, they could
> set up a formula similar to the leap year formula that said "add leap seconds
> *here*", and we could all write it into our time library codes (and our
> definitions of software "conformance") the way we do the leap year adjustments.
> 
> But in fact (mainly due to somewhat chaotic variations in the circulation
> of the molten iron core deep inside), the Earth's rotation *doesn't* seem
> to be very predictable, at least, not at the fine-grain needed for choosing
> leap seconds.  So what they do is *measure* the rate, and when the discrepancy
> between the rotation and "atomic time" gets "large enough" (by some rules
> that were written down when Coordinated Universal Time was defined by the
> ITU in 1970), they schedule a leap second at the next standard opportunity
> (June or December) so that the difference bewteen UTC (cesium beam atomic
> clock mean time) and UT1 (Earth rotation time) never exceeds 9/10'ths of
> a second.
> 
> So, yes, again, there was politics involved when Coordinated Universal Time
> was set up in 1970, but since then they've just "turned the crank" on the
> rules for adding leap seconds. By which I mean, no *new* politics (which
> is what your statement implied to me) is currently involved in deciding
> when to add a leap second.
> 
> +---------------
> | Daylight time is not a problem, by contrast, because machines largely
> | can be programmed to anticipate the occurrence of daylight time.
> +---------------
> 
> And if your machine *did* have equipment for measuring the Earth's rotation
> (say, an automatic star-tracker) and if it had the "rules for adding a leap
> second" [set in 1970] programmed into it, it could anticipate the need for
> a leap second as well as the ITU and the "UTC" consortium... but unfortunately
> neither can anticipate the future need for a leap second very well! This
> old Earth just ain't very cooperative!
> 
> -Rob
> 
> p.s. Imagine if the variation in the Earth's rotation were several orders
> of magnitude higher, e.g., so that the number of days in a year were a
> random variable with a mean of 365.24 but a standard deviation of, say,
> 3 or 4 *days* (instead of the current SD of less than a second). How might
> *that* affect our notion of computing with "time" (not to mention social
> issues)?  [Hmmm... Sounds like an idea for a science-fiction novel in there
> somewhere...]
> 
> If abyone can think of a good solution for *that* problem, it would probably
> work even better for our actual current situation.
> 
> -----
> Rob Warnock, 8L-855             ····@sgi.com
> Applied Networking              http://reality.sgi.com/rpw3/
> Silicon Graphics, Inc.          Phone: 650-933-1673
> 2011 N. Shoreline Blvd.         FAX: 650-964-0811
> Mountain View, CA  94043        PP-ASEL-IA
From: Kent M Pitman
Subject: Re: Representing Time
Date: 
Message-ID: <sfw7lsef2wm.fsf@world.std.com>
Kelly Murray <···@IntelliMarket.Com> writes:

> In any case, my thoughts are to have two functions
> that return a non-consing integer time value, (current-date)
> and (current-time), which seperates a date from the time within
> the date.  (current-time) is a millisecond timer that rolls
> back to zero at the start of each day, which might only
> be "required" to be accurate to one second.

Gack!  You can't have that!  Maclisp had (STATUS DATE) and (STATUS DOW)
and it was a disaster.  I always had my code call (STATUS DOW) [day of week]
first, then (STATUS DATE), then (STATUS DOW) again to make sure the day
of week hadn't changed in between the first and second call.  (I made the
bold assumption that the code wouldn't take more than a day to execute and
that it was save to iterate only once. :-)  But my point is that it has
to be the same function that returns this information--it can't be different
functions or people will code buggily.  I don't mind if it returns two
non-consing values, of course.

> (current-date) is an integer with bit fields for the numeric
> day, month, year, and timezone, structured such that the
> year field is the highest bits and thus can expand past a fixed
> field (e.q. 9999) yeilding a bignum at some point, and years before
> 0 can also be represented as negatives (have to verify that).

> Then have a function to extract the components from the (current-date)
> value, (decode-date (current-date)) -> year, month, day, tz
> with zero values indicating "don't care",

I wonder if people would wonder about why a timezone was needed for a date.

Why would you want zero to mean "don't care"?  Is there some reason
you can't use NIL (or :unspecific)?  I think picking a don't-care type
that is type-equivalent to a do-care type is an invitation to
accidentally lose.  e.g., consider where you compute 3 months after a
given month by adding 3.  Suddenly your don't care type looks legit
and you forget it came from an illegal source.  I'd rather a
wrong-type-arg error.

> except for the year, maybe -1 is really zero
> (though perhaps make Year 0 non-existing would appease the
> non-christians...  Actually is there a Year Zero??  ;)

No, there is no year 0.  That's why there's a big fuss about the millenium
change.  TECHNICALLY it's the 2000-2001 boundary that is the millenium
change.  Not that anyone cares about that.  With the Y2K hype, a lot 
of people are focused on that date.  And anyway, everyone really cares
about when the "2" appears.
 
> Then there is an class DAY that has these two fields: [...]
> (method day-month ((d day))
>  (aref '("" "Jan" "Fed" ..) (date-month (day.date d))))

Let's not make a FEDeral case out of it.  "Feb" maybe. :-)
 
Btw, you'd want #(...) not '("..."), too.

> (method http-date-850 ((d day))
>  (format nil "~..." (day-month d) ...)
> 
> I think this is very flexible and efficient.
> This can make logging more efficient since logs could
> be grouped by the day, and only the (current-time)
> would need to be recorded for each log.
> As well, if only a date is needed, just (current-date)
> could be used.  Only if both date and time are needed
> would an allocated structure be required.
> A function to convert the two integer values to
> a CommonLisp UT shouldn't be difficult to write.

I dunno about these details--not having thought about them much--but I agree 
something like this generally seems useful and I'm getting pretty tired
of implementing junk like this over and over in applications.

We need a standard place to put things like this.

> Then methods could be defined (and subclassed) to generate string
> representations from the value.
From: Kelly Murray
Subject: Re: Representing Time
Date: 
Message-ID: <36F289B9.344D0984@IntelliMarket.Com>
Kent M Pitman wrote:
> 
> Kelly Murray <···@IntelliMarket.Com> writes:
> 
> > In any case, my thoughts are to have two functions
> > that return a non-consing integer time value, (current-date)
> > and (current-time), which seperates a date from the time within
> > the date.  (current-time) is a millisecond timer that rolls
> > back to zero at the start of each day, which might only
> > be "required" to be accurate to one second.
> 
> Gack!  You can't have that!  Maclisp had (STATUS DATE) and (STATUS DOW)
> and it was a disaster.  I always had my code call (STATUS DOW) [day of week]
> first, then (STATUS DATE), then (STATUS DOW) again to make sure the day
> of week hadn't changed in between the first and second call.  (I made the
> bold assumption that the code wouldn't take more than a day to execute and
> that it was save to iterate only once. :-)  But my point is that it has
> to be the same function that returns this information--it can't be different
> functions or people will code buggily.  I don't mind if it returns two
> non-consing values, of course.

Excellent suggestion:

(current-time) => millseconds, date
(current-date) => date

the second value could be ignored if not needed.
This would complicate the day class though, since it couldn't
use simple :initforms for the components which could
be overridden by the call to make.

(class day ()
 (date)
 (time)
 )
(method make-day ()
 (let (time date) = (current-time)
   do
   (make 'day :date date :time time)
   ))

> 
> > (current-date) is an integer with bit fields for the numeric
> > day, month, year, and timezone, structured such that the
> > year field is the highest bits and thus can expand past a fixed
> > field (e.q. 9999) yeilding a bignum at some point, and years before
> > 0 can also be represented as negatives (have to verify that).
> 
> > Then have a function to extract the components from the (current-date)
> > value, (decode-date (current-date)) -> year, month, day, tz
> > with zero values indicating "don't care",
> 
> I wonder if people would wonder about why a timezone was needed for a date.

I wonder too, it naturally seems to be related to the daytime,
since that is where the "correction" is mostly connected,
but it's gotta go somewhere right?  Got a better idea?

> 
> Why would you want zero to mean "don't care"?  Is there some reason
> you can't use NIL (or :unspecific)?  I think picking a don't-care type
> that is type-equivalent to a do-care type is an invitation to
> accidentally lose.  e.g., consider where you compute 3 months after a
> given month by adding 3.  Suddenly your don't care type looks legit
> and you forget it came from an illegal source.  I'd rather a
> wrong-type-arg error.

You can't fit "nil" into a 5-bit integer field..
Are you suggested the zero value be eliminated?

I'm not certain it is that useful, but you seemed to want
such a concept in any earlier post.

Basically, I don't think code should be manipulating the bitfields
directly.  Adding 3 months to a date could roll into another year,
so you really can't do simple arithmetic on dates.
UT has the appearance of being able to do it, but it really is
not the appropriate interface in my opinion.  


In any case, simple arithmetic comparisons would be valid on
the date integer, since it would be [year|month|day],
Feb 5 1990 would be a larger value than Jan 31 1990,
and larger than any date in 1980.

A "incf" method on day.month could be used that "does the right thing".

> 
> > except for the year, maybe -1 is really zero
> > (though perhaps make Year 0 non-existing would appease the
> > non-christians...  Actually is there a Year Zero??  ;)
> 
> No, there is no year 0.  That's why there's a big fuss about the millenium
> change.  TECHNICALLY it's the 2000-2001 boundary that is the millenium
> change.  Not that anyone cares about that.  With the Y2K hype, a lot
> of people are focused on that date.  And anyway, everyone really cares
> about when the "2" appears.
> 
> > Then there is an class DAY that has these two fields: [...]
> > (method day-month ((d day))
> >  (aref '("" "Jan" "Fed" ..) (date-month (day.date d))))
> 
> Let's not make a FEDeral case out of it.  "Feb" maybe. :-)
> 
> Btw, you'd want #(...) not '("..."), too.
> 
> > (method http-date-850 ((d day))
> >  (format nil "~..." (day-month d) ...)
> >
> > I think this is very flexible and efficient.
> > This can make logging more efficient since logs could
> > be grouped by the day, and only the (current-time)
> > would need to be recorded for each log.
> > As well, if only a date is needed, just (current-date)
> > could be used.  Only if both date and time are needed
> > would an allocated structure be required.
> > A function to convert the two integer values to
> > a CommonLisp UT shouldn't be difficult to write.
> 
> I dunno about these details--not having thought about them much--but I agree
> something like this generally seems useful and I'm getting pretty tired
> of implementing junk like this over and over in applications.
> 
> We need a standard place to put things like this.
> 
> > Then methods could be defined (and subclassed) to generate string
> > representations from the value.
From: Fernando D. Mato Mira
Subject: Re: Representing Time
Date: 
Message-ID: <36F2398F.34EAA47A@iname.com>
Kent M Pitman wrote:

> No, there is no year 0.  That's why there's a big fuss about the millenium
> change.  TECHNICALLY it's the 2000-2001 boundary that is the millenium

That's the traditional way of counting imposed by some religious people a long
time ago. But given modern research that places Christ's birth at about 4 years
before what was thought, so they should accept year 0,
so that the error is reduced by one year.

So, in essence,

1. The century starts at 2000 for compatibility.
2. We already in the 21st century. Damm! We missed the party!

--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1                   email: matomira AT acm DOT org
CH-2007 Neuchatel                 tel:       +41 (32) 720-5157
Switzerland                       FAX:       +41 (32) 720-5720

www.csem.ch      www.vrai.com     ligwww.epfl.ch/matomira.html
From: Peter Arnold
Subject: Re: Representing Time
Date: 
Message-ID: <1douydd.1ul96pqbn1hmoN@modem-80.methylphenidate.dialup.pol.co.uk>
Kent your date/time suggestions are superb.

I'd like to see inclusion of provision for date/time intervals.  Ie.
rather than just a date as in 1 April 1999, I'd like a representation of
an interval which has a start and end slot as in next week, or he lived
80 years and died in 1990.

The translation between date systems (religeous, city, bomb, or
otherwise based) should not be too difficult, but handling of date
uncertainty seem a hill to climb.  To some extent, any date needs to
include the context in which it is defined, eg. noon  in Boston,
Linconshire, England is a different time from noon in Boston Mass, US;
as might be "about lunch time" for a postal worker or a banker.

Rather than impose integer style technical constraints on dates,
wouldn't it be better to embrace the intrinsic ambiguity of how dates
are used and represented in human life.  Ie. include boolean and
probability factors.

I have in mind an image of a theoretical line stretching from minus
infinity to plus infinity.  The zero point can be calibrated against any
reference.  As I microscope in on it, I can see atomic clock increments
scaled on it, and also other clocks too.  Stepping back, I can lay a
date or time interval along this line as a dumbell, fuzzy at each end
due to its uncertainty.  Perhaps a date is just an interval where the
two ends coincide.

Computationally I can tell whether this date or interval overlaps with
another date to some degree of certainty.  And translate dates between
any perspectives.

Often when dealing with real human dates, as one's understanding of the
veracity of some dates increases, so one can infer greater reliability
or accuracy of other dates (and unreliability of still others).  The
propagation of consequences are what make for subtle and at times
critical errors worming their way into our understanding of dates and
times.  In genealogy, criminology, workflow, archaeology, paleantology,
geology, ... there are many situations where non-rigorous (and perhaps
over rigid and presumptive) date representations lead to significant
problems.

I think that this is a fertile area for Lisp work.  That is to provide a
powerful date/time representation with infinite precision, which has a
powerful grip on uncertainty, and allows a rich input/output
prepresentation with a wide set of default parsers.  So to encourage the
research and development of applications which address some of the
weakness that we live with due to poor date/time representation.

Oh, and all in as compact and non-redundent a storage represenation as
possible.