+;;; In August 2003, work was done in this file for more plausible
+;;; timezone handling after the unix timezone database runs out in
+;;; 2038. We assume that timezone rules are trending sane rather than
+;;; insane, so for all years after the end of time_t we apply the
+;;; rules for 2035/2036 instead of the actual date asked for. Making
+;;; the same assumption about the early 1900s would be less
+;;; reasonable, however, so please note that we're still broken for
+;;; local time between 1900-1-1 and 1901-12-13
+
+;;; It should be noted that 64 bit machines don't actually fix this
+;;; problem, at least as of 2003, because the Unix zonefiles are
+;;; specified in terms of 32 bit fields even on, say, the Alpha. So,
+;;; references to the range of time_t elsewhere in this file should
+;;; rightly be read as shorthand for the range of an signed 32 bit
+;;; number of seconds since 1970-01-01
+
+;;; I'm obliged to Erik Naggum's "Long, Painful History of Time" paper
+;;; <http://heim.ifi.uio.no/~enag/lugm-time.html> for the choice of epoch
+;;; here. By starting the year in March, we avoid having to test the month
+;;; whenever deciding whether to account for a leap day. 2000 is especially
+;;; special, because it's disvisible by 400, hence the start of a 400 year
+;;; leap year cycle
+
+;;; If a universal-time is after time_t runs out, we find its offset
+;;; from 1st March of whichever year it falls in, then add that to
+;;; 2035-3-1. This date has two relevant properties: (1) somewhere
+;;; near the end of time_t, and (2) preceding a leap year. Thus a
+;;; date which is e.g. 365.5 days from March 1st in its year will be
+;;; treated for timezone lookup as if it were Feb 29th 2036
+
+;;; This epoch is used only for fixing the timezones-outside-time_t
+;;; problem. Someday it would be nice to come back to this code and
+;;; see if the rest of the file and its references to Spice Lisp
+;;; history (Perq time base?) could be cleaned up any on this basis.
+;;; -- dan, 2003-08-08
+
+