(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).

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?)

--

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    k...@niclos.com

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.

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.

Btw, you'd want #(...) not '("..."), too.

We need a standard place to put things like this.

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.

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

(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)
   ))

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".