There's two basic ways that TZ values can appear: * according to POSIX rules * optional system-specific forms, preceded by a leading colon
In Solaris, the system specific form is zoneinfo names, and the further extension is present that if it doesn't parse according to POSIX rules, a zoneinfo name is assumed even if no leading colon is present (for compatibility with the BSD heritage of SunOS 4.x, which IIRC also used zoneinfo files, I suppose). Adjusting to changes in timezone definitions affecting TZ values specified with the zoneinfo form don't require changes to libc to update; changes affecting values expressed in the POSIX form may, with the present implementation of localtime(3c). See the portion of environ(5) for TZ http://docs.sun.com/app/docs/doc/816-5175/6mbba7f0b?q=TZ&a=view for the rules on how the value should be structured. Note the phrase near the end: "Implementation specific defaults are used for start and end if these optional fields are not specified." Then see the code: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/gen/localtime.c#1118 and the static data table earlier in the file: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/gen/localtime.c#366 Note the comment that "posixrules" (a symlink pointing to a zoneinfo file) could eventually be used to eliminate hard coded data. If that change were made, it might be possible to avoid future changes to libc for the sake of changes in timezone rules. I don't know why that change hasn't been made, although I suspect a major concern would as always be backwards compatibility; that is, a very high level of confidence that the change wouldn't cause problems for customers. However, to my mind at least, any change in timezone rules, whether implemented in libc or via zoneinfo files, should ideally be done in single-user mode. The larger problem is that processes only read the timezone information the first time they need it; they never see changes while they're running after that. And indeed, unless they were written to deal with it, even if it were magically possible for them to see the changes (like defining a new signal and adding a handler to the library to automatically reload timezone info on receipt of that signal), processes using a TZ value affected by DST would likely not produce (in some sense or another) consistent results. That could be true in other situations, too; even a regular change to/from DST (not affected by a rules change) produces either duplicate human-readable times, or a jump forward. And some POSIX style values may only be valid for a finite amount of time. IMO, in a perfect world, all stored time values would be UTC or even real Julian dates (a large floating point number, not the 1-365 value often misnamed as a Julian date), except that for collaboration tools (like dtcm/rpc.cmsd) that (unlike current behavior) should ideally store time converted back to UTC _and_ the storer's TZ value (so that if someone schedules a recurring event for 10am local, that would be adjusted on display for the rules in effect for the storer at that time, and further adjusted for how that converts to the viewer's rules at the time; that would handle global collaboration across timezones with different DST rules. Further, only human-readable values strictly for display purposes (to include printing, but not stored log files) would be shown in local time. If processes voluntarily observed those limitations, those that displayed times or accepted interactive input could perhaps be safely modified to pick up updates affecting interpretation of their TZ value transparently to the user. But that's a whole lot of discipline in what processes do with time values that simply doesn't exist and isn't mandated by any standard (nor even thought about much, unfortunately). So real-world actions have to be robust (ensure consistent results) in the face of whatever foolish things processes may have been written do (at least, anything that isn't explicitly described as undefined behavior). The most consistent result is achieved when the patches are applied in single-user mode. That way, no apps are running when the change is applied; previous to dropping to single-user mode, they were all doing things the old way, and after returning to multi-user mode, they'd all be doing things the new way. So not only would the same set of rules apply for any one process's duration, they'd apply across processes for the entire time the OS was up in multi-user mode. Now if you know for certain that no app on your system might be using a TZ value affected by the rules changes (to include in log output that might ever be subject to follow-on processing), you could probably postpone the patches, and further postpone the reboot after that. But my guess is that the patch READMEs are written to err on the side of caution, rather than attempting to explain everything one would have to check to know that one could safely avoid a reboot. Perhaps if you have a high-end service contract, you could ask about that last point, and get more authoritative advice tailored to your particular situation. For free, you just got all the answer that another outside participant (me) is going to give you. Hope it helps. This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list [email protected]
