How do you generate POSIX time zone strings?
Hi, I am hoping this is the correct alias for this question (apologies of not). I am trying to find a straight forward way to generate POSIX time zone strings for the current year. For example, if this function were run on machine which has TZ set to US/Pacific in 1997 it would generate: PST8PDT7,97/3:00:00,300/1:00:00 Any suggestions welcome. Currently my best thought is parsing the zoneinfo files and generating them that way, which is quite tedious. Thanks, Tony
Date: Wed, 19 Mar 1997 13:19:11 -0800 (PST) From: Tony Glenning <tony@hape.Eng.Sun.COM> For example, if this function were run on machine which has TZ set to US/Pacific in 1997 it would generate: PST8PDT7,97/3:00:00,300/1:00:00 [*] First, perhaps you could explain a little why you want to do this, since you lose information when you generate Posix strings from Olson-style strings. Second, assuming you want to do this sort of thing, why would you want to generate [*]? It's better to generate the following instead: PST8PDT7,M4.1.0/2:00:00,M10.5.0/2:00:00 [**] since [**] will work in years other than the current year. [**] isn't as good as US/Pacific, but it's better than [*]. Here's how to generate [**] without parsing the zoneinfo files. Run GNU Emacs, load-library cal-dst, and invoke (calendar-current-time-zone). If TZ is US/Pacific, it should return (-480 60 "PST" "PDT" (calendar-nth-named-day 1 0 4 year) (calendar-nth-named-day -1 0 10 year) 120 120) and it's easy to generate [**] from this value. If you can't use GNU Emacs in your application, look at cal-dst's source code for ideas about how to do it. GNU Emacs doesn't parse the zoneinfo files; it just uses ANSI C localtime and gmtime like a good citizen.
Hi Paul, Thanks for your response.
First, perhaps you could explain a little why you want to do this, since you lose information when you generate Posix strings from Olson-style strings.
Currently JavaStations (i.e. JavaOS) gets its time from a time server. It then gets a time zone string from a DHCP server in order to calculate the local time. I want to find a straight forward way to generate the time zone strings which will be sent to JavaOS from the DHCP server. The string is limited to 256 characters.
Second, assuming you want to do this sort of thing, why would you want to generate [*]? It's better to generate the following instead:
PST8PDT7,M4.1.0/2:00:00,M10.5.0/2:00:00 [**]
since [**] will work in years other than the current year. [**] isn't as good as US/Pacific, but it's better than [*].
Now my ignorance is showing. I am not too familiar with all the varients of the POSIX strings. If you (or anyone else) could send me the standard (or a reference to the standard) regarding these strings, that would help out. Also, what is an "Olsen-style" string? As you state, this second form *is* better than [*], because 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.
Here's how to generate [**] without parsing the zoneinfo files. Run GNU Emacs, load-library cal-dst, and invoke (calendar-current-time-zone). If TZ is US/Pacific, it should return
(-480 60 "PST" "PDT" (calendar-nth-named-day 1 0 4 year) (calendar-nth-named-day -1 0 10 year) 120 120)
and it's easy to generate [**] from this value.
If you can't use GNU Emacs in your application, look at cal-dst's source code for ideas about how to do it. GNU Emacs doesn't parse the zoneinfo files; it just uses ANSI C localtime and gmtime like a good citizen.
This is an interesting suggestion. Although emacs itself is not an option (because this string is potentially generated by the DHCP server), if emacs used a good implementation, I don't mind borrowing :-). 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) - but I appreciate the suggestion. I guess I was hoping that there might be better way to find the transition times than processing the timezone file or using zdump or doing a binary search. Thanks again, Tony
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.
Tony Glenning wrote on 1997-03-21 01:43 UTC:
I am not too familiar with all the varients of the POSIX strings. If you (or anyone else) could send me the standard (or a reference to the standard) regarding these strings, that would help out.
The POSIX format for describing a time zone rule in the TZ environment variable is defined in ISO/IEC 9945-1:1996 (ANSI/IEEE Std 1003.1, 1996 Edition), Information technology--Portable Operating System Interface (POSIX) Part 1: System Application Program Interface (API) [C Language], 896 pages, ISBN 1-55937-573-6, IEEE order number SH94352-NYF. Price: 120 USD (first copy for IEEE members: 84 USD). You can order this standard as well as all other IEEE standards directly from IEEE: phone: +1 908 981 1393 (TZ: eastern standard time) 1 800 678 4333 (toll free from US+Canada only) fax: +1 908 981 9667 e-mail: stds.info@ieee.org Information about POSIX and other IEEE standards is available on <http://stdsbbs.ieee.org/> and some information about POSIX on <http://www.knosof.co.uk/posix.html>. Unfortunately the full standard documents are only available as books or on CD-ROM, not on the Internet. Markus -- Markus G. Kuhn, Computer Science grad student, Purdue University, Indiana, USA -- email: kuhn@cs.purdue.edu
participants (3)
-
kuhn＠cs.purdue.edu -
Paul Eggert -
Tony Glenning