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@zk3.dec.com Tue Nov 11 12:40:27 1997 ## Old-Return-Path: <tomp@zk3.dec.com> ## To: tz@elsie.nci.nih.gov ## Cc: Tom Peterson <tomp@zk3.dec.com>, simons@zk3.dec.com, dlong@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 ## ## ##