Backward compatibility of tzfile?
Hi, Is the intent that successive versions of the tzfile format will be compatible with older implementations of localtime.c, date.c, etc.? Obviously they wouldn’t be able to take advantage of any new information, but is the idea they’ll still be able to read it? I wasn’t able to find anything in the man pages about this. Thanks, Debbie
Deborah Goldsmith wrote:
Is the intent that successive versions of the tzfile format will be compatible with older implementations of localtime.c, date.c, etc.? Obviously they wouldn’t be able to take advantage of any new information, but is the idea they’ll still be able to read it?
Yes, that sort of backward-compatibility has been a goal.
Paul Eggert wrote:
Deborah Goldsmith wrote:
Is the intent that successive versions of the tzfile format will be compatible with older implementations of localtime.c, date.c, etc.?
Yes, that sort of backward-compatibility has been a goal.
Case in point: the files now contain tables of 64-bit information which allow 64-bit code to work correctly on dates past 2038-01-18. But the files *also* contain redundant, parallel tables of 32-bit information usable by 32-bit code. (Naturally 32-bit code will have problems in 2038, but there's no way around that.) The format is such that a version-1 (32-bit) reader will cleanly read the 32-bit data and cleanly ignore the 64-bit extended data that it has no knowledge of.
participants (3)
-
Deborah Goldsmith -
Paul Eggert -
scs＠eskimo.com