Date: Thu, 20 Mar 1997 17:43:16 -0800 (PST) From: Tony Glenning <tony@hape.Eng.Sun.COM> The client then gets a time zone string from a DHCP server in order to calculate the local time.... The string is limited to 256 characters. I couldn't find any mention of a time zone string in the DHCP RFCs (1533 and 1541) so I guess you're thinking of extending DHCP to support time zone names. In that case I suggest that you look at section 6 of: ftp://ftp.isi.edu/internet-drafts/draft-newman-datetime-01.txt for ideas about how time zones and network protocols. I am not too familiar with all the varients of the POSIX strings. They're described in POSIX 1003.1 section 8.1.1. That section of the standard hasn't changed since 1003.1 first came out. What is an "Olson-style" string? It's a string like "US/Pacific"; it is the name of a set of time zone rules. handling multiple years solves the problem of JavaStations booting on the last day of the year and getting old time zone string info from the DHCP server. Sorry, it doesn't solve the problem; it just ameliorates it. The Olson extension to POSIX TZ strings is as accurate as humanly possible; POSIX TZ strings are merely approximations. For example, the current time zone rules in Israel cannot be represented as a POSIX string (except one year at a time), since they keep changing the rules. And in some locales a year sometimes contains more than two transitions. It may be impractical to keep the complete set of Olson tables on your client; I'd guess they'd take only 64 KB compressed, but you don't want to put them in ROM because they're always being updated. Perhaps you should extend your protocol a bit. For example, the client might send the server a time value T; the server could respond with a POSIX-style TZ string S, along with the boundaries of the contiguous region of time surrounding T in which S is valid. That way, the client needs to interrogate the server only for time values that fall outside the time regions that the client already knows about. From looking at the source, emacs uses binary searches to isolate the transition times within the year. This seems a little tedious and no better than processing the timezone file (to me) Binary searches like that are standard operating procedure in this area. Many implementations of the mktime function use binary search. Also, I believe the latest Olson zdump uses a binary search, and that earlier versions of zdump ``knew'' more about the time zone file format but Olson changed zdump to use the binary search method in the interests of portability and maintainability.