A couple of days ago, I posted something to this list about how to go about changing the tz file format to support a 64-bit time_t value. I have heard nothing back. I was looking through the tzcode to see if this problem has been addressed already and found the following comment in the zic source.
** 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.
So, has anyone been looking into this issue? As I noted earlier, the current tz file format doesn't scale well to a 64-bit time_t and all of the possible additional timezone transitions that result from the addition years that can be represented. As OS vendors (including the one that I used to work for) consider what to do with time_t when their OS adds 64-bit support and how to deal with 2038, they might be tempted to come up with their own solution if it doesn't get addressed by the elsie code. alan
alan perry wrote:
A couple of days ago, I posted something to this list about how to go about changing the tz file format to support a 64-bit time_t value. I have heard nothing back.
I've been thinking about the problem a bit, since I'm interested in adapting the code to Java, which has a 64-bit millisecond time count with the same epoch as Unix time_t.
As I noted earlier, the current tz file format doesn't scale well to a 64-bit time_t and all of the possible additional timezone transitions that result from the addition years that can be represented.
Actually, the current format is quite suitable (doubling the size of all time_t's in it, obviously). It just becomes necessary to drop the idea that timezone files are good from now until the End Of Time. The idea of setting an explicit expiration date has been around for a while, but not IMHO implemented yet. A 64-bit version of zic can set the expiration date based on information in the source files, or simply to some sufficiently remote date like 2100. Time zone data changes fairly often anyway, and 2100 will see most of us safely dead. :-) -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5)
participants (2)
-
alan perry -
John Cowan