How do you generate POSIX time zone strings?

Paul Eggert eggert at twinsun.com
Fri Mar 21 07:03:11 UTC 1997


   Date: Thu, 20 Mar 1997 17:43:16 -0800 (PST)
   From: Tony Glenning <tony at 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.



More information about the tz mailing list