changing time_t to an unsigned int would give another
68 years without any of the size/performance problems
mentioned in Tom's email.
joel
## From tomp(a)zk3.dec.com Tue Nov 11 12:40:27 1997
## Old-Return-Path: <tomp(a)zk3.dec.com>
## To: tz(a)elsie.nci.nih.gov
## Cc: Tom Peterson <tomp(a)zk3.dec.com>, simons(a)zk3.dec.com, dlong(a)zk3.dec.com
## Subject: 32-bit 2038 issue
## X-Mts: smtp
##
##
## Has anyone considered what to do about time zone files and the 32-bit 2038
## issue? This comment from zic.c sums up the problem:
##
## > /*
## > ** The tz file format currently allows at most 32-bit quantities.
## > ** This restriction should be removed before signed 32-bit values
## > ** wrap around in 2038, but unfortunately this will require a
## > ** change to the tz file format.
## > */
##
## With Y2K bringing attention to time-related problems, there's an increasing
## awareness/concern about the 2038 issue as well. People know it's not just a
## system clock setting issue. The limitations affect projected dates used by
## applications as well. Problems are already cropping up where financial
## institutions can't generate amortization data for 40, 50, etc year loans and
## the like. I expect there are other practical examples as well.
##
## As new 64-bit UNIX platforms are emerging, there's a trend toward 64-bit
## time_t's. While this certainly eliminates the 2038 limit, it also creates a
## problem for time zone data files. A time zone file filled with data spanning
## 64-bits of seconds-based time would be huge, not to mention the performance
## problems of accessing it. Some ideas for addressing this problem are:
##
## 1) Expand the date/time boundaries for time zone files to a specific range.
## This would have to balance file size vs anticipated application needs.
## Perhaps an upper limit corresponding to the year 2100 or 2200 would suffice?
## Regardless of the range set, this approach only delays the problem.
##
## 2) Find some way to mimic what the zic compiler does at run-time. This might
## involve generating some kind of algorithmic data for each time zone which can
## be used to calculate future transition times, etc on-the-fly. I'm not sure
## this is possible or practical given the varied complexity of time zone rules.
##
## 3) Other ideas???
##
## Also, with 64-bit time_t's, the tm struct becomes the limiting factor.
## Boundary checks now become an issue for localtime()/gmtime() instead of
## mktime(). This is a problem for standards at a mininum. While mktime() has
## the (somewhat ambiguous) -1 return value for non-representable times, no such
## provision is defined for localtime()/gmtime().
##
## Any ideas or precedent for addressing this issue?
##
## thanks,
## - Tom
##
## =====================================================================
## Tom Peterson | DIGITAL UNIX Development Environment
## Digital Equipment Corporation | Phone: (603) 884-7550
## 110 Spit Brook Road ZKO3-2/W17 | FAX: (603) 884-2257
## Nashua, NH 03062-2698 | Email: mailto:tomp@zk3.dec.com
##
##
##
