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