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
Date: Tue, 11 Nov 1997 15:25:00 -0500 From: Tom Peterson (USG) <tomp@zk3.dec.com> Some ideas for addressing this problem are: 1) Expand the date/time boundaries for time zone files to a specific range. The boundaries should be expanded to an arbitrary range, so that our descendants don't have to worry about this problem. Also, while we're on the subject, I'd prefer a format that didn't have any arbitrary limits. For example, I'd like to remove the arbitrary limit of at most 255 time zone abbreviation characters. Personally, I'd prefer a text file, and if it were well designed, it wouldn't take more room than the current format (it'd probably take less). Text is more portable and easier to debug. The current C9X draft also makes some other provisions for time zones that I haven't had time to digest; these other provisions may also require changes to the tz file format. We've also been kicking around ideas for rule timestamps, to help maintenance (e.g. for DHCP). Perhaps it is finally really time for a tz file format redesign. Of course we should maintain a backwards compatibility option for people who need to use the old file format. 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. The code already needs to deal with arbitrary POSIX.1 strings at run-time, so it should be practical to do this. One possibility is to compile rules into POSIX.1 strings in the table, and then decode this at run-time. 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(). The C Standard says that gmtime can return a null pointer, and this certainly seems like the right thing to do if tm_year cannot represent the year. I believe that current practice is for localtime to return a null pointer with an unrepresentable time (e.g. negative time_t values on some hosts), even though the C Standard does not allow for this. This sounds like a bug in the C Standard, and perhaps it can be fixed in C9X.
参加者 (2)
-
Paul Eggert -
Tom Peterson