On a Unix system, SBCL should read the same timezone database that all the
other software uses, so that results are consistent from one application to
another. Hence, it should either use the standard libc libraries or read
the timezone files directly. If an organization is serious about correct
time calculations, it will standardize the zone database files across the
entire organization so that everyone gets the same data. I know of more
than one company that puts copies of the Unix time zone databases on each
Windows host so that the Windows machines can get the time calculations
right, when necessary.
Currently, C programmers serious about time calculations past 2038 have
probably rolled their own time routines, unless they're lucky enough to be
using a machine with a 64-bit time_t type. Mostly, people don't care about
timezones that far in the future, however. For instance, a bond may mature
on a a particular *day* 50 years from now, not at a particular time, such as
3:00 pm July 23, 2054, Beijing local time. One exception is electricity,
which must be delivered during specific hours.
Note that politicians change the time zone rules fairly frequently, so no
one can really count on them to stay constant into the future.
Anyway, the best options are:
a. Use the C libraries and disallow time calculation after 2038. Wait
patiently for a 64-bit time_t to arrive.
b. Parse the time zone files and reimplement the C time zone library
algorithms in CL.
Choice b has a number of advantages. For instance, a Lisp implementation of
the routines could allow one to do time zone conversions in several zones
simultaneously without serious overhead. To do that today in C requires
constantly changing the TZ environment variable, which is slow. The Lisp
time conversion routines could take a time zone parameter, instead of
working off the global TZ value.
Also, Common Lisp's handling of time zones seems to be quite broken, so we
need a better time API anyway. It's not OK to treat a time zone as just an
offset in seconds from GMT. Time zones are geographic areas that follow a
set of wall clock adjustment rules. Erik's proposal to represent them as
symbols seems reasonable.