-;;; Returns two values:
-;;; - the minutes west of GMT.
-;;; - T if daylight savings is in effect, NIL if not.
-(sb!alien:def-alien-routine get-timezone sb!c-call:void
- (when sb!c-call:long :in)
- (minutes-west sb!c-call:int :out)
- (daylight-savings-p sb!alien:boolean :out))
+;;; 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