On May 3, 2013, at 6:32 AM, Robert Elz <kre@munnari.oz.au> wrote:
Rather we should be encouraging people to use the binary output files from zic for almost all purposes when they need something more than standard libc functions provide. And if that means documenting that format, more than is already done, then let's do it.
Do we need more than tzfile(5), which we already have? ("More" over and above "making HTMLified man pages available from http://www.iana.org/time-zones or a page under it", which is something I think wout be a good thing to do.)
It is already difficult to the point of almost impossibility to make much in the way of changes to that file format, as it is understood by system's libc functions, that we cannot alter - and even where libc is normally shared (and so can be updated if needed) nothing compels users to use the shared version - static program linking works on every system I'm aware of.
$ cat static.c #include <stdio.h> #include <time.h> int main(void) { time_t now = time(NULL); printf("%s", ctime(&now)); return 0; } $ gcc -static -o static static.c ld: library not found for -lcrt0.o collect2: ld returned 1 exit status and it's $ uname -sr Darwin 12.2.1 better known as $ sw_vers ProductName: Mac OS X ProductVersion: 10.8.2 BuildVersion: 12C3012 And also: $ gcc -static -o static static.c ld: fatal: library -lc: not found ld: fatal: file processing errors. No output written to static collect2: ld returned 1 exit status and it's $ uname -sr SunOS 5.11 better known as "the OS component of Solaris 11". And, no, as far as I know clang won't help on OS X and Sun C^W^WOracle Studio won't help on Solaris. Both OSes have an explicit policy of *disallowing* static linking, so that they can change implementations of system APIs under the hood *without* having to worry about out-of-date implementations being built into statically-linked binaries. (And, yes, even process 1 runs dynamically-linked code.) However, there are *other* UN*Xes where static linking *is* allowed, so we still have to worry about that. As random832@fastmail.us suggested, we can add new information to the end. There's also a version field in the header, and the only check currently done by our localtime.c is to see whether it's '\0' or not; the "new format", with 64-bit time support, has '2' in that field, and, unless some other reader is out there, we could set it to '3' for a new version with additional information at the end (and maybe some information in the reserved field if necessary).